[OSM-talk] Thoughts on OSM design, and looking forward and back
tom at compton.nu
Tue Feb 23 22:40:24 GMT 2010
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
> 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
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
> 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 Hughes (tom at compton.nu)
More information about the talk