You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Mrinal Wadhwa <mr...@gmail.com> on 2009/01/16 10:26:54 UTC
Re: [ESME UI TEAM] Sprint planning call results
Hi Bill,
Thank you for documenting these and sending them across ... I've been down
with viral fever this past week so could not make it to the meeting ... the
medicines have had me fairly sedated this past week :)
*NOTE: *I'm including the dev mailing list into this email ... keeping with
the apache spirit of "if it didn't happen on the mailing list it didn't
happen"
Just so you know, my personal strengths lie in developing interfaces and not
in designing them, so at all stages I would prefer you and Anne take lead
with the design and I can help with the development. Keeping this in mind, I
think, my involvement will make most sense in goals 4 and 5 from your list
...
4. Make a preliminary list of API calls the UIs will need.
-- As David said, I understand the current API fairly well, so I
can take up this task.
5. Implement the first stage end-user UI.
-- this obviously has a dependency on 1 and 2 ... if they can be completed
by 30th of Jan, I can dedicate a considerable amount of time on the
following weekend of 31st, 1st and a few days after that to churn something
useful out before the sprint ends on the 6th.
Apart from this I can help with whatever else you need my help with.
>> We didn't discuss the current AIR client, and I haven't played with the
current version.
>> Mrinal, do you have specific plans/desires you'd like to address during
this sprint with respect to the AIR client?
The only goal for the AIR for this sprint is to get rid of all the known
bugs that are recorded in the google code project.
>> It was suggested that a good way to organize and publish tasks,
priorities, progress, etc. was to use a Google spreadsheet
I don't like this way of doing this because in the past I've noticed that
not everyone pays attention to the discussion on the shared spreadsheet and
people come back with questions/remarks/objections at a later stage when
decision on the subject had already been made by people who involved in the
discussion on the spreadsheet ... I would prefer if we setup a bug/task
system like Jira or something somewhere, because then alert emails could be
forwarded to the mailing list and that keeps everyone involved ... we could
also use the google code bug system or whatever else everyone else prefers.
Thank you,
Mrinal
_
http://www.mrinalwadhwa.com
On Fri, Jan 16, 2009 at 1:34 AM, Bill Fernandez <bi...@billfernandez.com>wrote:
> Dear Anne and Mrinal--
>
> First, Anne, I hope your trip to Iceland is safe and happy.
>
> There was a sprint planning teleconference this morning. Here are the
> point that are relevant to us as the UI team.
>
> o The sprint will end on 6-FEB-09.
>
> o It was suggested (but not decided) that the entire team have scrum calls
> a couple of times a week at times alternating between 8:00 AM and 9:00 AM US
> Pacific Time (GMT-8).
>
> o The team wants a new end-user UI based upon my suggestions.
>
> o The team also agreed that we need a suitable UI for the back-end
> administrator.
>
> o The team wishes progress to be made in stages, where we produce
> incremental improvements and additions over time.
>
> o Our goals for this sprint are:
> 1. Map out an overall UI architecture for the web client.
> 2. Design the first iteration of the new UI.
> 3. Scope out requirements for the back-end admin UI.
>
> o Our stretch goals for this sprint are:
> 4. Make a preliminary list of API calls the UIs will need.
> 5. Implement the first stage end-user UI.
>
> o My first question to Mrinal and Anne is whether there are things not on
> the above list you think should be there? The second is, is there anything
> that shouldn't be there?
>
> o My third question is what would each you you like to contribute during
> this sprint?
>
> o I would think that it would make sense for me to be responsible for
> mapping out the general end-user UI architecture, and also for writing the
> UI spec for the first iteration of a new UI, because both those tasks are
> extensions to the comments document I wrote. If this is agreeable I will
> proceed with these, but even so I would appreciate it if each of you could
> make a list of features/functionality the architecture should provide places
> for, and indicate which you think are essential for the first iteration of
> the new UI.
>
> o Beyond that, I was wondering if either of you would undertake the task of
> accumulating requirements, use cases, etc. for the back-end admin UI.
>
> o Dick Hirsh said he could help create the list of back-end admin
> requirements.
>
> o David said that he wants to migrate the current API to (a) be more
> REST-ful, and (b) be JSON based so as to be client-platform independent. He
> said Mrinal is pretty knowledgeable about the current API, so I wonder if
> you (Mrinal) would like to work on compiling a suggested list of APIs.
>
> o We didn't discuss the current AIR client, and I haven't played with the
> current version. Mrinal, do you have specific plans/desires you'd like to
> address during this sprint with respect to the AIR client?
>
> o I see that Mrinal is already listed as an Apache incubator committer. I
> need to sign Apache's Contributor Licence Agreement (CLA), and then follow
> up to become a committer. Anne, what's your status? Are you legally able
> to provide code (HTML, JavaScript, etc.) to the Apache repository, and will
> you be able to sign the CLA soon?
>
> o It was suggested that a good way to organize and publish tasks,
> priorities, progress, etc. was to use a Google spreadsheet, to which our
> team will have write privileges and the public will have read privileges.
> I'll look into setting something like that up and we can see how it works.
> Or if you prefer a different method, please suggest it.
>
>
> OK, so I think those are all the highlights from the meeting. What do you
> think?
> --Bill
> --
>
> ======================================================================
> Bill Fernandez * User Interface Architect * Bill Fernandez Design
>
> (505) 346-3080 * bill@billfernandez.com * http://billfernandez.com
> ======================================================================
>
Re: AW: [UI] Suggestions for Mrinal
Posted by Bill Fernandez <bi...@billfernandez.com>.
@Dick--
I read the use cases on the ESME blog long ago. I don't remember
them being that useful at the time; maybe because they seemed pretty
obvious and basic.
At present what would be useful would be a list of functionality that
you want to be sure doesn't get missed. Don't need a formal
presentation, just a description of each need or objective.
What do you think?
--Bill
At 8:48 AM +0100 1/19/09, Hirsch, Richard wrote:
>@Bill
>
>Do you need support with use cases for the UI? I created some use
>cases for the original UI (
>http://blog.esme.us/the-origins-of-esme-selected-use-cases/) why
>don't you see if this a format that you like and if the selected use
>cases help you. They might be outdated but I think they provide some
>indication of where we are going.
>
>D.
>
--
======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design
(505) 346-3080 * bill@billfernandez.com * http://billfernandez.com
======================================================================
AW: [UI] Suggestions for Mrinal
Posted by "Hirsch, Richard" <ri...@siemens.com>.
@Bill
Do you need support with use cases for the UI? I created some use cases for the original UI ( http://blog.esme.us/the-origins-of-esme-selected-use-cases/) why don't you see if this a format that you like and if the selected use cases help you. They might be outdated but I think they provide some indication of where we are going.
D.
-----Ursprüngliche Nachricht-----
Von: Bill Fernandez [mailto:bill@billfernandez.com]
Gesendet: Freitag, 16. Jänner 2009 14:38
An: esme-dev@incubator.apache.org
Cc: Bill Fernandez; yojibee@gmail.com; esme-dev@incubator.apache.org
Betreff: [UI] Suggestions for Mrinal
Mrinal--
sorry you've been sick. Thank you for offering to lead tasks 4 and 5:
At 2:56 PM +0530 1/16/09, Mrinal Wadhwa wrote:
>I think, my involvement will make most sense in goals 4 and 5 from your list
> 4. Make a preliminary list of API calls the UIs will need.
> 5. Implement the first stage end-user UI.
With regard to the first stage end user UI, I think you could easily
start at any time, putting in place the framework I outlined in my
comments document. I suggest the following:
o Get the three-pane (three-column) main window layout working, with
the show/hide buttons.
o Get the messages formatted per the comments document.
o Get the overall shrink/expand functionality working (to make the
window tiny vs fullsize). Initially don't worry about trying to put
activity indicators in the shrunken view.
o Make it lay out and behave well under these conditions:
-- Safari and Firefox on Mac OS
-- Safari, Firefox and IE6 on Windows XP
-- Safari, Firefox and IE7 on Windows Vista
-- Firefox on Linux (?)
-- With browser font-size upsized or downsized two increments by the user.
o In the left pane make it possible to insert sections (that
show/hide their contents when you click the section titles) and make
it possible to insert items in the sections that affect the display
in the center and right panes.
o Make it so that clicking an item in the left pane can display the
center and right panes separately, or combine them into one large
pane (as when displaying help or "about" info).
o Put in place dummy pages for help, about, policies, etc. (whatever
the static info pages were that I mentioned in the comments doc).
o Create the help system infrastructure, basically consisting of a
data structure and method for defining a hierarchy of help pages,
plus a two-pane window that shows the table of contents as a tree in
the left pane and a selected help page in the right pane.
o Create the login system. Make the login page and main end-user UI
take turns occupying the same window. The login "page" should
include the stub logic for registering as a new user, recovering
password, opening the help system, contacting an administrator, and
logging in. When the user logs out of the main UI, the login page
should replace the main UI in the same window.
All that should keep you busy for a long time :-).
What do you think?
--Bill
--
======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design
(505) 346-3080 * bill@billfernandez.com * http://billfernandez.com
======================================================================
[UI] Suggestions for Mrinal
Posted by Bill Fernandez <bi...@billfernandez.com>.
Mrinal--
sorry you've been sick. Thank you for offering to lead tasks 4 and 5:
At 2:56 PM +0530 1/16/09, Mrinal Wadhwa wrote:
>I think, my involvement will make most sense in goals 4 and 5 from your list
> 4. Make a preliminary list of API calls the UIs will need.
> 5. Implement the first stage end-user UI.
With regard to the first stage end user UI, I think you could easily
start at any time, putting in place the framework I outlined in my
comments document. I suggest the following:
o Get the three-pane (three-column) main window layout working, with
the show/hide buttons.
o Get the messages formatted per the comments document.
o Get the overall shrink/expand functionality working (to make the
window tiny vs fullsize). Initially don't worry about trying to put
activity indicators in the shrunken view.
o Make it lay out and behave well under these conditions:
-- Safari and Firefox on Mac OS
-- Safari, Firefox and IE6 on Windows XP
-- Safari, Firefox and IE7 on Windows Vista
-- Firefox on Linux (?)
-- With browser font-size upsized or downsized two increments by the user.
o In the left pane make it possible to insert sections (that
show/hide their contents when you click the section titles) and make
it possible to insert items in the sections that affect the display
in the center and right panes.
o Make it so that clicking an item in the left pane can display the
center and right panes separately, or combine them into one large
pane (as when displaying help or "about" info).
o Put in place dummy pages for help, about, policies, etc. (whatever
the static info pages were that I mentioned in the comments doc).
o Create the help system infrastructure, basically consisting of a
data structure and method for defining a hierarchy of help pages,
plus a two-pane window that shows the table of contents as a tree in
the left pane and a selected help page in the right pane.
o Create the login system. Make the login page and main end-user UI
take turns occupying the same window. The login "page" should
include the stub logic for registering as a new user, recovering
password, opening the help system, contacting an administrator, and
logging in. When the user logs out of the main UI, the login page
should replace the main UI in the same window.
All that should keep you busy for a long time :-).
What do you think?
--Bill
--
======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design
(505) 346-3080 * bill@billfernandez.com * http://billfernandez.com
======================================================================