esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Fernandez <>
Subject Re: [UI] Other UI-related issues
Date Sun, 08 Feb 2009 23:36:45 GMT
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 

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 

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 
>a. on message level:
>Reply to
>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:
>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  *  *

View raw message