Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of yojibee@gmail.com designates
 72.14.220.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=cc:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=NE4PhgEUb8qQGirZfHt1HWc8ZyekBN89RmCzSEKsfoI4fZpMRmdJQKeq5m4KO1J56T
         Xysgs/NTxHdmTHpvf/e6OwqVW32NBMyKfS+7gzEb2nHq9Qaza74d/4C+0VIrUIwHUHkE
         RqV9RBkctGorSJak8p7GCaJZ2pabDkQrXZJuI=
Cc: esme-dev@incubator.apache.org
Message-Id: <A983B00E-9D8B-4FFE-844D-02FB330479FD@gmail.com>
From: Anne Kathrine Petteroe <yojibee@gmail.com>
To: Bill Fernandez <bill@billfernandez.com>
In-Reply-To: <p06240813c5b51243975c@[192.168.0.65]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [UI] Other UI-related issues
Date: Tue, 10 Feb 2009 22:30:19 +0100
References: <E7A29DC6-E34E-41FC-938B-2B9066D5121C@gmail.com>
 <p06240813c5b51243975c@[192.168.0.65]>

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  *  bill@billfernandez.com  *  http://billfernandez.com
> ======================================================================