Allow users to 'maximize' the map/edit area

[CloCkWeRX]

As a contributor, particularly when I am editing, I often wish to maximize the screen real estate given to the editing tool.

I rarely will use left hand side links while editing, as I have swapped from a 'passive viewing' to 'interaction, task specific' mode of use.

A simple 'hide left hand nav' UI toggle would greatly improve the editing experience.

[systemed]

You can do this in either P2 or iD by pressing 'M' for maximise. If there were to be a visual equivalent it would probably be better implemented in the editor rather than the Rails port.

[tomhughes]

As @systemed says, both editors can already do this, and any issue of better exposing that functionality to the user is a matter to take up in the relevant editor's bug tracker.

[CloCkWeRX]

That solves the problem for the edit case, the read only slippy map does
not present a user with that option - the issue at heart is how the
overall layout can respond to smaller screen resolutions (maximise the
"doing" area of the site when ever editing style interaction takes place)

Try some of the following:
On an ipad, swap to portrait mode, use the export function. Result -
significantly Reduced area avail to see the item you are exporting via
slippy map.

On gnome, use the ability to dock your browser at half the width of you
screen, so you can focus on a second task while you map - perhaps conduct a
search and interact with results. Again, a large amount of screen real
estate is eaten up by left hand nav

On android, view the map. This is the opposite as the design turns
responsive, but there is no way to search or make any of the left hand
items available.

A universal solution would be to fix this as a website layout issue (allow
user control of the menu ui) rather than multiple solutions that work in
limited scenarios.

On Saturday, July 13, 2013, Tom Hughes wrote:

As @systemed https://github.com/systemed says, both editors can already
do this, and any issue of better exposing that functionality to the user is
a matter to take up in the relevant editor's bug tracker.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/331#issuecomment-20917042
.

[tomhughes]

Making the site more responsive is something that will almost certainly happen with the ongoing design work but it won't be relying on people manually showing and hiding things, rather it will simply respond to the available screen size.

[CloCkWeRX]

If that's the case, can you please link to open feature requests or other
areas that describe the ongoing design work, so that I can contribute?

IE the last two feature requests I've opened have been closed quite
quickly, which is in a fair amount of contrast to threads like
http://lists.openstreetmap.org/pipermail/talk/2013-July/067442.html; which
was a fairly positive dialog.

Right now, the vibe I'm getting from this is suggestive that contributions
are not welcome; as you are shutting down this conversation without proper
solutions.
IE: The opening of two further requests for a half solution doesn't solve
it; nor does putting forward "ongoing work" will solve the issue with pure
responsive design.

The current public site does not respond well to a variety of scenarios as
I put forward before; and I would appreciate it if you ran through them and
gave serious thought to decent approaches to fixing them.
I would wager you have not done this; otherwise you'd probably have come to
the conclusion that toggle/slide out menus are actually a common responsive
design technique - if you google for it ("responsive menus"), a significant
number of solutions are based around the sort of technique I'm suggesting
here.

I'm more than happy to hack away on frontend work like this; or contribute
to other initiatives to rework the UI to solve this problem in a different
way - I just need a little bit of encouragement and to be pointed in the
right direction, rather than WONTFIX'd.

On Sun, Jul 14, 2013 at 5:10 PM, Tom Hughes notifications@github.comwrote:

Making the site more responsive is something that will almost certainly
happen with the ongoing design work but it won't be relying on people
manually showing and hiding things, rather it will simply respond to the
available screen size.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/331#issuecomment-20932997
.

[tomhughes]

Well there aren't really tickets for something as general as "design work" rather as people have specific suggestions (or preferably code) they open an issue or pull request for that.

See for example the form restructuring pull (#300) which was merged recently, or the map UI one (#328) which is currently in progress. Those are some of the first pieces of the changes.

Something as vague as "make the site more responsive" is not really a very helpful thing to have open though, as it not concrete enough to have a point when we would be able to objectively say that it is done.

So far as the concrete suggestion of providing a user triggerable way to make the map full size, that is not a direction I think we should pursue, so unless there is community consensus to the contrary I am inclined to leave that closed.

Improved responsiveness to differences in client screen size is definitely a goal though - we do already make the map more or less full size on phone size displays (or at least try to) but we should probably have a better story for intermediate size displays like tablets.