On 2013-01-15 22:48, Pierre GIRAUD wrote:
On Mon, Jan 14, 2013 at 9:59 PM, David Schmitt <[email protected]
<mailto:[email protected]>> wrote:
On 2013-01-12 21:18, Pierre GIRAUD wrote:
The most important (new) things to notice are:
- tiles can be accessed in a read-only mode,
- with this in mind, tiles url (in the address bar) can be
used to be
shared to someone else. This might be useful to use a tile as
reference
in a discussion between mappers,
That was something quite confusing about the task manager: you had
to login to do *anything*. I see on the dev server, that it's still
a requirement to login to browse the tasks. Is this really
necessary? It would be nicer if a login would be *only* necessary
for "write" actions, like locking/commenting ?
You're right. Accessing a tile in read-only mode shouldn't require a login.
I'm not sure a user should be able to access a job without being logged in.
I'm not the one to decide for HOT, but as a user and for my own
installation, I don't deem that necessary.
- you need to explicitly lock the tile before working on it,
So I can load and edit things without locking? To my engineering
mind, that sounds like a recipe for conflicts. I do not understand
the use case. Is there a workflow, where one needs to lock the task,
but not load it into an editor? That would be better served with
"lock", "lock and load".
User may want to see it in an editor before they want to lock the tile
to work on it. But I agree that conflicts may happen if users forget to
lock the tile.
On the first round I tried to display the "load in editor" buttons only
after a lock, then decided to show them after selection. I can change it
back easily if this sounds better.
Being a lazy person, I'm primarily concerned to have another mouse click
in the workflow. Being a paranoid person, I'm concerned that forgetting
(more likely ignoring) it will lead to conflicts and duplicated work.
Perhaps the solution would be to render all buttons in a lock-and-load
variant, followed by a de-emphasized load-only button. Language-wise it
should probably be "edit" and "preview", putting the edit button in
normal color and the preview button in shades of grey to suggest which
one the user should use.
With my UX head on, "lock" also sounds very technical and
forebidding. Perhaps "Work on this" might be more inviting. Also in
the history "Locked by ..." does not describe what's happening. "X
started to work" or "X reserved the tile," might be more to the point.
Terminology is important. I agree.
I'm happy to share ideas about UX. This is something I'm really
sensitive to.
In MapCraft they're using the following words: "take", "abandon",
"reserved", "freed", "owner".
I'm open to suggestions if others have any.
Otherwise, I like the "Start to work on this", "X started to work on this".
The MapCraft terms sound ok to me too, although I'm not particularly
enthusiastic about "abandon". On the other hand, it might make sense to
use the same terms across tools, if(!) they really mean the same thing.
BTW, would it be possible to get a link/integration to one of those
whodidit services? Not everything that happens in a location is
going through the task manager.
https://www.google.com/search?__q=whodidit+openstreetmap
<https://www.google.com/search?q=whodidit+openstreetmap>
Can you elaborate how you see this integration?
For simple information, a link to the other tool with a proper bounding
box might suffice. For tight integration, it'd be cool to see a list of
"recent" changesets for the choosen task, to see more context.
On the downside, this might lead to information overload.
Similarly, when using the TM for remapping or QA work, I often wished to
get the exact tile I'm currently working shown in OSMI.
- comments are now required when marking a task as done or
(in)validating one,
What should users put there? Thinking back to the tiles I did, I can
only remember one or two tiles where I felt a comment was required.
Maybe a comment is not really required when marking a task as done.
In my opinion, it's required when invalidating though.
Agreed.
Thank you for your very important work on this. Mirroring Sam's
statement, I believe the TM to be an important tool to allow OSM sub-
projects to coordinate themselves.
Best Regards, David
- users have access to the tile change history.
Which surely helps making comments more useful. But required?
I'm not sure how important the locking is when an advanced user
wants to
(in)validate the work done on a job.
How about allowing validation without any lock. Or maybe we should
rethink the validation process.
Any thoughts?
I think locking is important when the workflow "expects" the user to
write to the tile.
Regarding the question of motivating people to re-take tiles for
validation, this too (like "lock") might be a problem of the used
word: "validation" sounds academic, important and of high
responsibility. As a arm-chair mapper with only very little
knowledge of the task's background, it is not my place to *validate*
edits. Perhaps call it "second-pass"? That could lower the barrier.
Also, I'm of the opinion that the data-user (in all of OSM) has to
do her own validation to see whether the data is up to the required
accuracy for the intended usage. Again this is not something someone
from the wider community can do. Third, real validation can be done
in batches, where much more than a single tile is pre-loaded into
josm, background tiles are downloaded in batches and then quickly
checked. This would not require locking or loading through the TM,
but only invalidating or accepting the checked tiles.
Best Regards, David
_________________________________________________
HOT mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.__org/listinfo/hot
<http://lists.openstreetmap.org/listinfo/hot>
--
-------------------------------------------------------------
| Pierre GIRAUD
-------------------------------------------------------------
_______________________________________________
HOT mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/hot
