Yes Serge, seems like I was thinking of a different issue than you
brought up.
Setting other tags based on a name selection from the preset bar is very
interesting. The current behavior (category -> details) should stay as
the most preferred (recommended) way of doing it but if preset search
results aren't good enough we could fall back to suggesting close name
matches and pre-fill known common details.
One immediate issue I see is that it might go against expectations and
confuse a user, like where did all this data come from? Right now they
select a category and one or two tags are added, which is pretty simple
to deduce. If we 'quick add' a bunch of details lots happens in a short
amount of time, which might be confusing. Maybe we can prompt
expectations with some kind of icon, message, or animation in some way,
I'm not sure.
Seeing as how the preset model used in iD already different from how
other editors work I'm more open to trying this out. Technically, I
don't think it would be too difficult, my bigger concern is about user
expectations and reasonable defaults. The name-suggestion-index is
already almost able to do this, we could simply rename the 'translation'
property to something like 'details' or 'prefill' and use whatever
values are in there. We could also keep the basic implementation of name
suggestions (category -> details -> type name -> suggest name and only
fill in the name value) for users who want more control over the process.
I'm going to look into the specific details of how preset suggestions
work and get John's thoughts on this. I see the value is doing this I'm
just not sure about prioritizing it right now with the inevitable unseen
technical issues and community push back. Basic name suggestions are
already done in iD (https://github.com/systemed/iD/compare/name-suggest)
and this name stuff has already been a pretty big tangent so I might
have to push this back to later.
Thanks for your thoughts, this has been helpful.
On 11/2/13 5:15 AM, Serge Wroclawski wrote:
Aaron,
I think you're conflating two separate issues, which is why things
seem more intimidating than they are.
I'm going to leave out any discussion about changing existing data-
since that's where things would get controversial quickly.
Instead, I'm going to focus on tagging issues in the editor.
In iD, when you create an object, you can use the search bar to create
an object with tags from a set of templates.
Name expansion is good, it's really good.
But while name=McDonald's is good.
name (or brand)=McDonalds
amenity=fast_food
cuisine=burgers
is great. And it's great for a few reasons
1. It makes it easy to add new information about a feature without too
much thinking about it. Right now, iD's search functionality makes
adding a new feature easily, but you have to know the category first.
If we have features fully searchable by name, we eliminate a step (category).
2. It reduces the chances for making a tagging mistake
Right now, I see people choosing the wrong category for features.
restaurant=yes, name=McDonalds.
Why do people make this error? Because they aren't looking at all the
categories and thinking about them, they just pick one quickly. And
for some people, this may be their first edit, so we can certainly
understand how they might want to just pick *something*.
3. It provides built in examples.
Everyone learns differently, but I learn by example. If I knew that
McDonalds is a fast-food, then I might ask "What's a Ruth Chris?" and
play with that.
4. It helps emphasize tags we want filled in
Some McDonalds have free wifi, others don't. If that's something we
care about (just as an example) then we can add it to the preset, thus
encouraging users to collect that information.
- Serge
_______________________________________________
dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/dev
