When designing for interactions such as sending invites from an event page where the entire process needs to be as quick and unintrusive as possible you generally want to avoid placing any obstacles in the way. As a product person, you have to deal in features as well as design, in messaging as well as business goals. These competing interests often require a minimalist’s aesthetic, a bit of discipline and the ability to just say “No”. Its hard enough to keep advanced functionality out of the way of accomplishing the simplest goals and from continually complicating the user experience as new features get appended on to an existing design. Striking the right balance of instructional messaging and interface simplicity is just as important. Sometimes, adding one more sentence on how to do something actually makes it harder to do the thing. Its always a balance act and often a compromise, usually subjective and rarely an exact science.
One constant sore spot for UI people is dialogs. Rarely do you want to introduce an obstacle that keeps a user from moving forward. Its sort of like driving down the road and being prompted over and over again “You are going straight, ok or cancel.” For one, you may have no idea what will happen if you decide to cancel. Will the car veer off the road into a ditch? Will it stop dead in its tracks screeching to a halt on the middle of the highway? If you do hit ok, how often will you have to tell the car to just keep going forward? “If I want to turn I’ll steer!” You want to shout as you slam your foot on the gas (or worse, the brakes). In most cases, you don’t want to stop progress just to tell someone that everything is okay.
Operating in this mode we try to avoid dialogs unless they are absolutely essential. In a recent release, we provided a timed message that notifies you that your invites were sent. After the notification fades a line of text remained offering confirmation and a link to the invitation. We spent several iterations tuning the length of time the notification remained and trying to make the confirmation text more visible. Clutching with white knuckles onto our UX bible we dogmatically tried to avoid introducing a confirmation dialog, but time after time we found that invite organizers were not seeing the message, did not know what next step they must take, and were experiencing basically what amounted to cognitive dissonance. So, we have reformed. Our latest patch includes a confirmation dialog. You will need to hit OK to continue. There is a close, but there is no cancel.
For those of you who experienced our previous version and have since received the confirmation, I’d love to hear what you think.
- By admin
- In technology
- Comments Comments
Ahh the iphone. That lovely sliding interface has infected the web. Here at iggli, we’re doing the “iphone slide” whenever we can. One of our current development projects is to try to capture a user’s RSVP to an invitation with a similar “sliding” interface technique. By using the “slide” we can drive the user to more screens to try to gather more information from them as to why they’re in, out, maybe without overwhelming them with a huge questionnaire up front.
Depending on the user clicking "I'm in", "Out", or "Maybe" the appropriate next screen slides in.
For instance, a user might RSVP for Donovan Frankenrieghter and say “I’m OUT!”…that’s great information…but WHY? Do you hate Donovan or do you just already have plans? It’d be great if we could capture that you really hate…I mean HATE…Donovan Frankenrieghter. So your RSVP status might be something like “I’m out. + I hate Donovan Frankenrighter”
We’ve seen some of this around the web more and more. One site that we found kinda nice was the panic.com “coda slider”. They use it to market the “coda ide”. This was developed by Niall Doherty as far as I can tell. Also, Joe Hewitt’s IUI , which attempts to mimic the native iphone TableView component is also useful.
This is how the typical slide viewer works
A typical slide show viewer works by having a fixed set of slides that move back and forth behind the “slide viewer”.
The slider developed by Niall Doherty works like a slideshow viewer but automagically adds a set of tabs on the top to move directly to any particular slide. It’s fun to use. And works good if you know before hand what the content is going to be.
But we need to change the content depending on what path the user takes through the process of an RSVP to an invitation. Similar to how the iphone TableView component works. For instance, the might say “I’m IN! + I already have my tickets.” or “Im IN! + I’ll get tickets for anyone that wants to go if you pay me back.” It’s kinda like choose your own adventure.
This is a grid viewer...a slide viewer on steroids!
Well, this means a decision tree or “grid” of slides backing the slide viewer. The only problem is that the “slide” is not just left to right, but up and down and sideways. That’s a little weird and doesn’t mimic the iphone “slide” which we’re trying to do.
We couldn’t find anything out of the box that supports exactly what we need…So we are building our own. Here’s the concept we’re working with right now. We want the slide to move left and right like a slide show viewer. But we want the user to drive the interface like a decision tree. So we’re combining a slide show viewer with a grid of slides.
This is a slide viewer backed by a grid of slides
So as the user selects different actions from any slide, the next slide (which may not be next to the current slide in the grid) is copied into the “on-deck” position of the slide show viewer, and then slides into view.
We’ll keep you updated on the progress and are hoping to release the code for all to use. Stay tuned.
Dehru Cromer
an iggli developer