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.
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/
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.
There was a plan for a bit to have less moving parts, so to just use the HTML we currently have, but put the new UI tech in underneath. Which could work perhaps, since the html could just be marked up with wicket stuff.
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.
Ok, so we should try to get some of his time before we even land in Italy? That may be trickier, but I can try.
Chris
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
-------------------------------------------------------------------------
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/
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.
I think the big question is, when do people learn about Wicket? If
we are going to make a Wicket crash course at Bolsena, that alone
will easily eat up 2 days (and btw, we need to schedule some time
for whoever is teaching to learn how to use Wicket for good. I did
read a Wicket book, but that was almost two years ago).
It may also be a good idea to buy a few copies of "Wicket in Action"
in PDF format (printouts won't be ready in time for the meeting).
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?
It may be a good idea anyways, so we'd start with 2 days of course whilst someone (you?) talks to the designer and make up a first cut
of the new UI, then we spend half a day talking all togheter about
the new design, and finally 2.5 days redoing the UI.
I agree here Justin; having an idea of what we want the end goal to look like would be very helpful going into the code sprint. I sent out a link to the document we put together last time; a refresh for GeoServer 2.0 would be a great resource.
Chris is the designer going to benefit from "face time" with the developer community? Or can we just get a document ready in time ...
Cheers,
Jody
Justin Deoliveira wrote:
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/
I agree here Justin; having an idea of what we want the end goal to look like would be very helpful going into the code sprint. I sent out a link to the document we put together last time; a refresh for GeoServer 2.0 would be a great resource.
Chris is the designer going to benefit from "face time" with the developer community? Or can we just get a document ready in time ...
Yeah, part of the issue is we just may not have time to get a document ready in time, so that's where the idea of sending him came. But I also think face time is always good. It'll also allow us to move more agilely and iteratively, as opposed to the designer just passing something over the fence.
Chris
Cheers,
Jody
Justin Deoliveira wrote:
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.