The votes so far:
* Create an intermediary UI
+1
* Skip the intermediary Web UI and concentrate on the "BillF" UI?
+5
Bill suggested this, so I would like to add this to the vote. (and
cast my vote for this suggestion)
o On the other hand, if the UI code (HTML, CSS, JavaScript, etc.)
would have to be redone from scratch, then maybe we can create an
interim UI that is also the first step in the evolution of the "BillF"
UI, and pursue both goals with one action.
The UI code will have to be redone from scratch, as the old/Mrinal's
UI code still contains Kirsten's graphics.
- Anne
On 7. jan.. 2009, at 18.12, David Pollak wrote:
My vote: Create an intermediate UI.
On Wed, Jan 7, 2009 at 12:17 AM, Hirsch, Richard <[email protected]
wrote:
Last night on the scrum call, we were discussing various options
for the
Web UI and I wanted to summarize what we were discussing and ask the
community on what option we should follow.
-Situation-
We currently have a Web UI running at the main ESME server at
http://esme.us. This version is very early iteration and has various
issues associated with it. It is also based on the old core code
based
at the Google Code site. We now have a new new ESME core code base
which is located at Apache. This version of the code at Apache is the
most recent code base and includes a better split between UI and
server
code. The Apache version, however, currently doesn't have UI code in
such maturity that we could use it to replace the existing Web site
at
esme.us. Bill has also created a description of a new ESME UI which
probably depicts what the next UI is going to look like. This
description is currently incomplete inasmuch as certain UI features
are
still not depicted.
-Vote-
The vote deals with the decision whether we want to build an
intermediary Web-UI based on the existing Apache Core or whether we
want
to skip the intermediary Web UI and focus on the "BillF" UI?
Choices (Please Vote!):
* Create an intermediary UI
* Skip the intermediary Web UI and concentrate on the "BillF" UI?
Once the community makes a decision on this issue, we will define the
associated tasks to support the decision.
Dick
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
