by John W. Long on December 19, 2009
One of the nice things I put together while I was working on
MemberHub.com was a LowPro
and Prototype-based date input control. Today, Five Points Solutions (aka
MemberHub) has released it as open source:
http://github.com/fivepointssolutions/dateinputjs
It’s fairly easy to use. Just wire it on to text field that you would like to
turn into a date input control and the DateInputBehavior does the rest. A
simple line like this:
Event.addBehavior({'input.date': DateInputBehavior()});
…will unobtrusively
wire it onto all input controls with a class of “date”. It’s pretty slick. I’m
sure you will like it.
Dan Webb (of LowPro fame) actually wrote a good portion of the code. We
discovered
date_selector.js
in the LowPro repository, found that it was about half of what we wanted, and
were able to modify it to suit our needs. Dan’s original version didn’t allow
the calendar portion to drop down or provide easy access for jumping forward
to another year or month. We added these features, styled it up rather nicely,
and have packaged the whole thing up in a nice little project on GitHub.
I, for one, am very grateful that Five Points has released their version as open
source. I have plans to see that it gets integrated into a little
CMS that I’m working on.
by John W. Long on December 16, 2009
I talked briefly about my javascript library
StatusJS in the article Tech Notes:
Radiant 0.9.0
RC1
but thought that it would be good to take the time to introduce it in more
detail as it is such a useful library.
We live in a time where Rails-style flash messages have become so common and
annoying in web applications that they litter the webscape like confetti in
the annual Thanksgiving day
parade. Enough
already! I know I just deleted that object! I know I just created a message!
Now a couple of folks have come up with creative ways to automatically hide
flash messages after a certain period of time or allow the user to manually
close the message, but both solutions have the annoying effect of causing the
content underneath to “slide up” once the message disappears. This can be
jarring for users that are working with content below.
Perhaps we need to rethink this whole concept. Maybe it is less important to
tell the user what they have just done and more important to tell
them about the work that is being done.
This is where StatusJS comes in. StatusJS provides a robust solution for
displaying progress messages to users while the work is being done.
So instead of displaying “Changes saved.” in a flash message after the form is
submitted, you display “Saving changes…” while the form is
submitting.
A bit of a paradigm shift mind you but something that Web applications should
have borrowed from desktop applications a long time ago.
So how does it work?
StatusJS defines a couple of global functions that make it easy to control the
status overlay, as the following code sample demonstrates:
showStatus(“Initializing…”);
setStatus(“Loading graphics…”);
setStatus(“Finished!”);
hideStatus();
The showStatus() function displays and centers a new status overlay,
setStatus() changes the status message and re-centers the overlay,
and hideStatus() hides the status overlay completely.
StatusJS also includes a LowPro behavior for
forms that makes it easy to add onsubmit status messages when a user
clicks a submit button.
To automatically connect the behavior with your forms, add the following line
to your application.js file (assuming you are doing Rails
development):
Event.addBehavior({’form’: Status.FormBehavior()});
This allows you to add a custom attribute to each of your forms that contains
the onsubmit status message:
<form action="/controller/action" onsubmit_status="Saving Changes...">
... contents of form ...
</form>
The form above would display a “Saving Changes…” progress message after the
user clicked the submit button.
There are a couple of additional configuration variables that are worth
noting. Normally you should set these variables in your
application.js file (assuming you are doing Rails development). It is
essential that application.js be loaded after status.js so
that the variables are not overridden by the defaults. Here is how it works:
// The size of the corner images. A value of 12 means square
// 12x12 pixel corners.
Status.CornerThickness = 12;
// The path, width, and height of the spinner image
Status.SpinnerImage = "/images/status_spinner.gif";
Status.SpinnerImageWidth = 32;
Status.SpinnerImageHeight = 33;
// The background and corner image paths
Status.BackgroundImage = "/images/status_background.png";
Status.TopLeftImage = "/images/status_top_left.png";
Status.TopRightImage = "/images/status_top_right.png";
Status.BottomLeftImage = "/images/status_bottom_left.png";
Status.BottomRightImage = "/images/status_bottom_right.png";
// Dim the background when a status message is displayed. Also
// prevents stray mouse clicks from having any effect.
Status.Modal = true;
At the moment, StatusJS requires prototype.js, effect.js,
and lowpro.js (all included in the GitHub project), but Sean Cribbs
is working on a JQuery port. It will be added to the main project once it is
ready for general use.
You can download StatusJS from GitHub here.
The project includes a small demo in the test directory that requires
Serve.
by John W. Long on December 4, 2009
I’ve been noticing recently that a lot of my e-mail of late is notification
related. I get a lot of e-mail from applications like Twitter and Facebook
that falls into this category. “Someone added you as their friend”, “X is now
following you”, “There is a new message in your Facebook inbox”, “A photo was
uploaded with you in it”, etc… These messages can normally be expressed in a
single line.
I often sort messages from different web services into their own folders.
Here’s an example of how my Twitter “inbox” looked earlier today:
As you can see, each of these notification messages can be displayed on a
single line. In fact, an entire summary of each e-mail message is expressed in
the subject line.
The Big Idea
So here is my big idea: What if a notification e-mail message like this was
formatted so that it would allow e-mail clients to handle them as a special
case?
This would allow an e-mail client to have a special pane that would show
recent notifications. You could also build rules that would do certain things
when a site sent you a notification. Like download the photo you were last
seen in to a special folder or display a small notification window (like a
Growl notification) or forward the notification to you as an SMS message on
your cell phone.
If the body of the e-mail contained a special part tailored for display, you
could even get a feed view that would look much like Facebook’s news feed
or perhaps your Twitter stream.
Probably the biggest win here in treating notification messages differently is
that normal messages begin to take center stage again. Your inbox would no
longer be filled with notifications from Twitter and Facebook. It would
contain the real stuff you need to deal with for your work or personal life.
The possibilities here are mind boggling. This could change the way we
communicate with each other.
All it would take would be for a major e-mail client like G-mail or Yahoo to
start handling messages this way and promoting the concept.
The Technical Jargon
I’m not familiar enough with the e-mail spec to completely outline how this
should be done, but I do have a couple of suggestions for how this could work
in practice.
First of all, I’d suggest that web services begin marking notification
messages with a special “X-Notification” e-mail header. The header could
include information about whether the message required some action from the
user or not. Other things that could possibly be included here would be flags
that would be read by mail servers as the message is passed along that would
determine the priority that it should be delivered. Lower-priority
notifications would not need to be delivered immediately.
Secondly, I’d suggest that the subject of the message be treated as a one-line
summary of the notification. Web services seem to be doing this already.
Thirdly, I’d also suggest that we add a new alternative part to a MIME encoded
message that would contain the compact rich notification summary suitable for
display in a feed of some kind (I’m thinking HTML here). The new part type is
essential because it would allow messages to be displayed in the new format
only if the e-mail client supported it, whereas older clients could continue
to display them as normal e-mail messages.
So this is my big idea. What do you think?
