Oh I totally agree. I wouldn't suggest we just do whatever is at the top of uservoice, not at all. If for no other reason that I'm the one paying for the work so I'm going to pick the stuff that coincides with a) being good ideas b) having support and c) I like... mostly there is an overlap there.
In terms of having a bazillion features - I hear you. I'm sticking to only things that the designer/html guy can do plus, maybe, the bug system. I can't of course have anything to do with routing as it's all kinds of stuff that you guys would have to implement. I really don't see the role of uservoice and the clones of it to be "just do what the people say at the top"... if anything most of the uses (and it lets you do this) mark ideas as 'under consideration' or 'rejected' pretty much like any bug system. The flip side of that though is what if the votes are right, in the end, and we're just ignoring the ideas because we don't like them? That's a hard one to call. Yours &c. Steve On Feb 23, 2010, at 3:40 PM, Tom Hughes wrote: > 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
