Hi Anne-- Responses threaded below. See what you think. --Bill
At 10:57 PM +0100 2/8/09, Anne Kathrine Petteroe wrote:
I would like to suggest a few changes regarding navigation.
There are a few functions which, in my opinion, needs to be easier to access.
Instead of having a top bar with icons above the three panes, I
would like to introduce a top and bottom navigation bar like we had
in Mrinal's UI.
There are two reasons for this:
1. I would move Help / Logout out of the UI window and place them
above this window, similar to twitter's current UI.
BF: I'm confused: these buttons already are in an area at the top of
the HTML-controlled area, and above the message-interaction area, and
this is already just like Twitter: only taking up less space.
It would free up space which can be used for entering tags/keywords
for instance. Tags and keywords are essentially a part of the
message, so maybe we should make this avaiable to the user in the
same pane he uses for entering the message? (right now these can
only be entered in the right sidebar)
BF: Regarding tags, I was assuming that tags would continue to be
entered inline in the message in the form #tagname. The tag menu in
the right pane is primarily intended for less expert users who need
assistance, or or for any user wanting to find out what tags are
already in use.
BF: Regarding keywords: What do you mean by this? My impression was
that that tag cloud simply shows the words most commonly used in
messages, and that we don't have a data type called "keywords". Am I
wrong? And if so, what's the difference between a tag and a keyword,
and how do you presently enter keywords in to a message?
2. The reason why I would like to move some functions out of the
three-pane view is that I would like to see the three-pane view
being used for sending/receiving messages only.
A top navigation bar could have: Settings / Help / Log Out / Personalization
BF: In my mind we already have a top bar that has Help and Log Out
(see first comment above). What am I missing?
BF: My thought was to make it possible for the ESME window to be as
small as possible and still be highly usable for those who don't want
it monopolizing their screen. To make it possible for the window to
be small we have to minimize the number of items that are always
onscreen and thus that always taking up screen real estate. I would
think that Settings / Preferences / Personalization are features that
are only occasionally accessed, and thus shouldn't be always onscreen
and always taking up space. What do you think?
In a bottom navigation bar I would like to see: Terms of Service /
Contact / Link to Blog / About Us
BF: I don't necessarily mind there being a bottom bar with controls
in it, but I don't understand the logic of the items you suggest.
The links you suggest are common for public information websites, but
ESME is intended as an internal, corporate tool that runs within a
corporate context. So...
o I do have a "Terms of Service", but in a corporate setting I felt
that "Usage Policies" is a more accurate and appropriate term;
although they have essentially the same effect.
o I do have "Contact" info and "About Us", but again they are cast in
a corporate form and placed in the "System Info" section of the left
sidebar.
o Since those are all occasional-use items, it seemed unnecessary to
have them permanently monopolize screen space that would be rarely
used (because people would rarely click these links), and by
accessing them through the left sidebar, which acts as the complete
table-of-contents for all information accessible through the ESME
end-user UI, they would be readily discoverable and available when
needed.
o As far as "Link to Blog", what blog are you talking about? Are you
assuming that each organization will have a corporate blog? I don't
think that's a safe assumption; and as an institutional resource
there's no one personal or departmental, etc. blog that makes sense
to link to. Now I can imagine an organization wanting to provide
links to other information tools (outside of ESME), such as the Human
Resources website, or a timesheet entry web application, etc., and
having links to these other tools could be placed in a footer at the
bottom of the UI, but it would be more scalable to place them in a
menu, which would then support as many or few such resources as each
organization desires.
o So what do you think?
Functionality which is in my opinion needs to be easier to access is;
-> Right now these functions are all "hidden" in the sidebars and I
think most twitter users would like to have a one-click access to
these.
a. on message level:
Reply to
Retweet
Add to favourites
I suggest we do this by adding small icons below/above/on the side
of the message itself.
BF: You probably missed that, but I described exactly that on page-70
of my comments document.
b. functionalities:
Search
URL shortening
The URL shortening could be a small icon on the bottom of the UI
window and the search could be sitting in between top navigation bar
and UI window for instance.
BF: I think that URL-shortening is a key UI element that we'll have
to have in the design, and that it will have to be easily and readily
available to experts and novices alike. I haven't thought about the
best way to do this, but you're on the right track with your thoughts.
BF: About search: That's also going to be important to get right,
and I think it's going to take some cleverness to get it right. I
don't think a single-line text box is going to be enough, but beyond
that I haven't thought about what kinds of searches will be the most
needed. Is that something you could think about, and maybe make a
suggestion about what things users will most want to search for and
what kind of results they'll want from their searches?
And we need to think about how we want to display conversations.
I suggest an inline drill down of the last 5 messages. If there are
more than 5 message the conversation should open in it's own window.
BF: Another area where we'll definitely have to be clever. The
first requirement is to figure out how we'll know what set of
messages constitutes a conversation and whether we want to support
threaded and branched conversations. Your 5-message idea sounds like
a possible approach, but I think we need to have a better idea of
what the size and shape of "conversations" will be.
--
======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design
(505) 346-3080 * [email protected] * http://billfernandez.com
======================================================================
