add "edit" button to mobile version

[ralfhauser]

on https://www.openstreetmap.org/node/846169263, I would like to add wheelchair=yes tag when on my mobile.
The responsive design unfortunately hides the "edit" button - so I cannot.
(I am logged in on my smart-phone)

[HolgerJeromin]

My default on android is: install the editor app Vespucci, after that use the "geo uri" in the share part of the website.

[ralfhauser]

I see the benefit of an app for power users, but for infrequent/novice users a minimal web interface would be good too ?

[tomhughes]

Enabling the button wouldn't really be very useful because iD doesn't really work in a useful way on a screen that small. Here's what it would look like on an iPhone 8+ for example:

[mmmatthew]

Here is a comment about adding mobile support to iD: openstreetmap/iD#5890 (comment)

[BjornRasmussen]

@tomhughes just press the inspect button on the top and iD becomes a lot better. I've been able to do a lot with iD lately, including adding service roads and buildings, using the validator to upgrade tags, and adding POIs, all from my smartphone.
The biggest barrier is getting to iD from the osm website.

[ralfhauser]

In my experience, 90% of novices are lost by not downloading an app from the app-store.

Questions:

1. is there any https://en.wikipedia.org/wiki/Progressive_web_applications as an interim step if someone wants to add "wheelchair"
2. if I could organize the financing for enabilng the pure web interface to allow to edit such tags, would that help ?

[Adamant36]

"In my experience, 90% of novices are lost by not downloading an app from the app-store."

I think most people edit OSM at this point probably also have OsmAnd installed on their cell phones. You can edited POI's pretty easily through that by holding down on the POI, clicking actions, and pushing the "modify POI" button.

As far as the financing question goes, its not really about that. There's been a lot of discussion and issues about making the main site more mobile friendly and that doesn't seem to be a direction the maintainers are interested in going in. Although, iD Editor has made some progress on it. Money isn't the barrier though. TomHughes can probably speak more to that if need be. Personally, I use to be really into the idea, but I've been less so lately. Apps are adequate and its fundamentally wrong in my opinion to just do things to satisfy "novices" in my opinion. They are extremely small segment of OSM users and 99% of us are perfectly fine with using either apps or desktops in absense of mobile support. That's just what I think though.

[simonpoole]

In my experience, 90% of novices are lost by not downloading an app from the app-store.

It is difficult to understand what you wanted to say there.

Questions:

1. is there any https://en.wikipedia.org/wiki/Progressive_web_applications as an interim step if someone wants to add "wheelchair"

2. if I could organize the financing for enabilng the pure web interface to allow to edit such tags, would that help ?

You don't need to organize the financing you need to organize the development as there is currently no mechanism to do anything with any funds received (you shouldn't underestimate the effort for a "tags only" editor that doesn't break things though).

[dieterdreist]

here’s iD on an iPhone7, the smaller screen phone, in landscape. It would be somehow working, although I would not suggest it for the novice editors. A user setting would be great (enable editing on mobile phones, experimental), which defaults to no.
There’s a problem with scrolling the sidebar, but it doesn’t seem a big issue to solve.

[simonpoole]

@dieterdreist IMHO that is a fairly to very naive assumption. For an essentially online only app to work -reliably- (as in not to be inundated with complaints about things going wrong during brownouts and outright outages) requires a substantial amount of work.

[dieterdreist]

Am So., 26. Mai 2019 um 11:36 Uhr schrieb Simon Poole < [email protected]>:

@dieterdreist <https://github.com/dieterdreist> IMHO that is a fairly to very naive assumption. For an essentially online only app to work -reliably- (as in not to be inundated with complaints about things going wrong during brownouts and outright outages) would need a substantial amount of work.

I agree it would be a substantial amount of work to make it a universally recommendable editor (in particular touch vs. mouse-controlled needs significant modifications) that's why I wrote "somehow working", for many edits (e.g. correcting a street name), it is more than sufficient. The very promising new "text mode" even allows for more complex modifications like shifting tags from one object to another.

[matkoniecz]

Enabling the button wouldn't really be very useful because iD doesn't really work in a useful way on a screen that small.

What about different list of linked editors that would depend on a situation? For example on Android Vespucci and StreetComplete are feasible candidates.

I assume that it is OK to use JS for system detection.

[danieldegroot2]

Here is a comment about adding mobile support to iD: openstreetmap/iD#5890 (comment)

See openstreetmap/iD#7639 .
(For other editors, see #799.)

cc: @ralfhauser

[tordans]

Its been a while since the decision to hide the edit button was made an I think we should change it now. My main reasons are…

• the edit button is part of the core story of the website. Just hiding is not the right thing to do to tell this story.
• iD editor is usable on todays mobile phones, so there is no reason not to link to it
• Quite a few mobile editors added "open in " feature and the comming policy will allow them to be added to the menu eventually Draft Ops policy for adding editor to Edit Button Dropdown operations#877 (comment) which we can prepare for now
• my personal experience (Mobile: Edit button hidden #4435) as a mapper is, that I want to go to edit to do some quick checks even on mobile … even if I don't plan an extensive edit session or any editing at all

From a conceptional and user experience point of view I think we should re-add the edit button.

@AntonKhorev you have been working on this parts of the code for a while now, do you see any technical blockers to unhide the edit button?

[gravitystorm]

I'm sure I've mentioned it elsewhere, but for clarity there is no "mobile version" of the website. The layout of the website (and in this case, the appearance of the edit button) is based on the screen width, so the edit button can appear on mobile devices with wide screens, and it can be hidden on desktops when the browser window is narrow. We also have three different layouts, not just two.

So the choice is at what screen width do we want to show the edit menu, and perhaps what items to we want to show on the edit menu for different widths.

I should also note here that although the layout is based on the screen width, it's also (currently) affected by the language that you are using, since the different page layouts are currently based on ensuring that the wider menus fit too. Finally your username also plays a part, since it's also shown in the top menu - you can give yourself a very long username, and the edit menu will show up only on very wide screens! The exact width at which we transition from the one-column layout (for small screens) to the compact-menu layout is therefore different for different people. I'd like to decouple these at some point, so that the layout is based on screen width directly, and only the menus are based on the menu width.

[tordans]

@gravitystorm what I am still unclear about: Would a PR to add the edit button to the small-nav Menu be considered?

[gravitystorm]

Sure! But I would want to see consideration as to whether it's useful and what any drawbacks might be. For example, I don't think it's useful to show iD when the screen width is so narrow that the save button isn't on screen! I think that might apply to many small-width devices like common mobile phone sizes.

But if someone wants to make the case for adding the menu, or doing something more sophisticated (e.g. encouraging landscape mode where that might help, or changing the selection of items shown on the menu depending on screen width, etc etc) then I would certainly consider it.

[AntonKhorev]

We also have three different layouts, not just two.

We have more than that because the following doesn't apply to the right sidebar:

I should also note here that although the layout is based on the screen width, it's also (currently) affected by the language that you are using, since the different page layouts are currently based on ensuring that the wider menus fit too. Finally your username also plays a part, since it's also shown in the top menu - you can give yourself a very long username, and the edit menu will show up only on very wide screens! The exact width at which we transition from the one-column layout (for small screens) to the compact-menu layout is therefore different for different people.

You can have one sidebar going into full width mode while the other staying on the side.

[simonpoole]

What I can't quite understand is why this is of sudden urgency, particularly given that the whole mechanism/labelling etc. might have to change based on whatever the OWG decides with respect to how to move forward with adding additional entries to the menu, to the point that "Edit" might not even be the appropriate heading.