I think its a good idea to bring along the designer. However i am a little confused about "replicating the old ui with new technology". Does this not represent a ton of work? I mean the old ui encompasses a lot of stuff that i would think a new user interface would cut out.
Plus I think that the html page design and workflow will drive how the underlying wicket application is structured. So I think doing some of that up front wold save time in the long run as well. My 2c, -Justin Chris Holmes wrote: > Hey all, so TOPP may be able to send a great designer to Italy, to help > with the interaction and web design of a new web admin tool. I thought > this might be a good idea, to have him spec out and build html for the > new admin interface. > > I had been thinking we'd just replace the backend UI technology during > the sprint, and do the actual UI rewrite later. But my thought on that > was that 1.7.0 would replace the UI technology and get stable, and then > 2.0 would be the new UI. But since 1.7.0 is just going to be the config > stuff, and hopefully rest interfaces, this means that it might be > advantageous to do the UI tech replacement at the same time as the UI > rewrite. Because I think it'd just slow us down a lot to fully > stabilize as 1.8.0. > > My other thought is that when replacing the UI with a new technology > we'll probably want to add in at least some of the little UI > improvements that Wicket offers. And then we'll probably be tempted to > fix the most egregious errors of the current UI, and UI improvements > will creep in, but won't be driven by a designer, and we'll end up > replicating work. I guess I'm also not convinced that it's going to > take 4 people 5 days to replace the UI tech. And then we'll either just > go to bug fixing, or do our own little ui improvements. And while we're > all together I'd prefer to more than just bug fixes. Also it'd be a lot > better to write tests, like functional tests perhaps with Selenium, > against what will be the UI. > > So my thought was that the designer could work in parallel with the > development work, and get a bit of stability with the UI tech > replacement, but start to move on to the UI html and interaction design > replacement at the end of the week. And if we don't get all the way > there we'll at least be ready. And our designer can get some real good > exposure to geo stuff. > > But these are just some ideas I've been thinking about. If we feel it's > going to be a waste to have him there then we don't have to send him - > like we should feel it's a desired thing, since it is going to cost TOPP > a good bit. So what do people think? > > Oh, and behind all this is a desire of mine to get some sort of > 'GeoServer 2.0' by foss4g, with feature freeze by mid-august at the > latest. But I don't want to set a super ambitious goal, so if we want > to cut things we should figure that out. > > Chris > > > > !DSPAM:4007,48347016306452090977483! > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > !DSPAM:4007,48347016306452090977483! > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > !DSPAM:4007,48347016306452090977483! -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
