esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hirsch, Richard" <>
Subject AW: [VOTE] Web UI options
Date Wed, 07 Jan 2009 09:56:55 GMT
I agree. The question is when do we replace the existing web client at 

I'm assuming that we will need some sort of a test server where the new UI is viewable. We
can then vote via the mailing list when enough functionality is present to replace the existing
web client.

Where should this test server be based? Stax, Apache, Dpp?


-----Urspr√ľngliche Nachricht-----
Von: Darren Hague [] 
Gesendet: Mittwoch, 07. Jänner 2009 10:51
Betreff: RE: [VOTE] Web UI options

>* Create an intermediary UI
>* Skip the intermediary Web UI and concentrate on the "BillF" UI?

Depends on our definitions. This will probably and up as me voting +1 for concentrating on
the "BillF" UI, but let's iterate towards that. This may mean that us server-side guys produce
something really ugly but functional as we go, and the more designer-based folks move &
style the elements of this ugly UI as we go. 

For example, the current Apache code is ugly and not fully functional, but the HTML templating
is there for the messages, which means that it is more designer-friendly than it was. In other
words, the UI separation from the back-end code is already at a stage where we can start to
make it look better than it does right now.

So what I am saying is this: let's NOT produce an intermediary UI in the sense that we have
a milestone which is "we have a functioning ESME with a bad UI", and the next milestone is
"BillF UI". However, the journey towards the "BillF" UI will mean evolving what we have right
now in stages, until we achieve that milestone - but during the journey we should strive to
make sure that the code will build to produce a functional ESME which gets more and more usable
until we achieve the "BillF UI" milestone.

Does that make sense?


View raw message