Hi Bill,
thank you for your comments.
I suggest that, in order for the UI development to speed up, you
continue working on a UI spec as outlined in your comments.
I may not agree with everything, but more it is more important to get
a UI up and running, than to discuss details endlessly.
Will you be able to finish the spec in this sprint?
Regards,
Anne
On 9. feb.. 2009, at 00.36, Bill Fernandez wrote:
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
======================================================================
