[OSM-talk] Thoughts on OSM design, and looking forward and back

[Tom Hughes]

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 (tom at compton.nu)
http://compton.nu/