On 23/02/10 22:12, SteveC wrote: > As you can see from uservoice, things you highlight like routing are very > important to people out there. You might also have seen the misconception in > blog posts back and forth last week with GIS guys that they thought OSM was > simply unroutable because we don't expose it. Properly explaining why that is > (bringing the service in house) and then doing it is I guess the right way > forward. > > As for the approach... I'm really not sure a hack weekend would work. Say we > got a designer in for a weekend. They'd actually want to sit in photoshop for > some period of time and then iterate the design, then code that the HTML, > then bolt all the functionality and so on. Could we really do any of the > first bits in a hack weekend?
Well as I said I started to think that it probably wasn't very practical either which is why I suggested trying to draw up some sort of brief that could be given to designer(s) > So I'd say it'd be more efficient and get wider input, to iterate it out here > on the interwebs and then code in the functionality over a hack weekend > maybe, or refine and tweak etc. It's difficult - people can design and propose and say "wouldn't be cool if" as much as they like but at the end of the day what gets implemented will be driven by the people that front up to do the work. The risk is that our usual crowd of architecture astronauts will design some fantastic all conquering web site with thousands of really cool features but then there will be nobody to implement it. > I know a bunch of people don't like uservoice, but it's actually got some > good stuff in there now and it's what I was planning to use to iterate the > design feedback. A bunch of people are using it, I posit because 1) it's so > easy and 2) you can vote nicely on things... I actually unsubscribed from the uservoice feed this morning I'm afraid because I wasn't finding it at all helpful. I'm just not sure you can design things by popular vote - part designing is knowing that sometimes you have to say no to something. Not everything that can be done should be done. Uservoice, as far as I've been able to see, doesn't really seem to have a concept of rejecting an idea. > Here's my proposal for next steps: > > * put the html etc in svn or git or whatever > * use uservoice for consensus on features to fix first (have a look, lots of > good stuff) > * pay the html guy to go do it > * iterate like this 5-10 times at least > > if you think there's a better and more inclusive system than uservoice, or > anyone wants to do the actual work, please of course let me know but right > now I'm just trying to actually move it forward bit by bit... You see my concern, and yes it's probably an elitist attitude, is that uservoice is too inclusive. Certainly implementing whatever rises to the top on uservoice is not a reasonable way to design anything in my opinion. Just as an example, the top thing on uservoice right now is something that we probably can't do on any large scale. I mean I'm not quite sure exactly what it's suggesting but it seems to be that we should either add lots more layers to our map, or that we should have some sort of system to provide links to lots of other maps drawn using our data. The problem is that either of those things would probably kill all those other sites. My best suggestion for an "implementation" of it would be to have a wiki page listing uses of our data and then include a link to that page on the main site - that probably strikes a balance between publicising what can be done an not driving too big a tsunami of traffic to a third party site. > It would be helpful to get deep and broad thoughts from the sysadmins on what > the different bug system technical requirements are fo ryou guys too? You see to my mind uservoice isn't a bug tracking system at all - it's some kind of crazy popularity contest. Maybe it will work for this design problem but I don't think it will work for us in general. A bug tracking system needs basic concepts of responsibility for a bug and the ability to close it out, whether because it has been completed or because a decision has been taken not to do it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
