Progress update on kiosk UI design

[James William Yoon]

Excellent points--thanks, Tona!

My only concern -and, as I've understood in design meetings, is also yours-
> is the amount of space that the path can take on the screen. I fact, I think
> that *flatland* is not far from the textual breadcrumb. The difference,
> besides its graphic treatment, is that it's not based on the architecture of
> the application, but on the steps the user has done.
>
> In this sense, I wonder if it wouldn't be more clear to the user to have
> the bubbles ordered from left to right (as he's used to), and to use the
> same size for all the bubbles. This way, the bubbles would occupy a single
> row, and the rest of the screen would remain free for the contents.
>
> On the other hand, I also wonder what would happen when the number of steps
> that the user has done increases beyond what can be displayed on the screen.
>
>

This is indeed one of the issues we considered. You're right that the
'flatland' idea is not far from a textual breadcrumb--in a way, it's simply
making the breadcrumb much more tangible.

The screen space, however, that the UI would maximally take is limited by
the number of levels in the would-be screen hierarchy. Specifically, our
current idea is to display at most one screen from each level in the
hierarchy, which, in our current information architecture, is three (a very
manageable number).

In this sense, it isn't the full path of a user's experience that's
presented (like a browser navigation history might), but merely the shortest
path to/from the root (much like the conventional breadcrumb).

(We've also played around with the idea of displaying multiple would-be
screens on the same level of a hierarchy to allow comparisons between same
level content, but the interaction complexity involved is likely to break a
three minute interaction threshold that we're trying to keep under.)

Thanks for the feedback!

Cheers,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100225/4d51ca8c/attachment.html>