Id: feature request: remind users to save periodically

[kriscarle]

Remind users to save after a certain number of edits or a certain amount of time.

We've noticed in our mapathons for http://loggingroads.org that users (especially new users) don't always realize that they need to save periodically and end up with a large number of edits that 1) slows the browser down and 2) are more likely to have conflicts with other mappers in the mapathon.

[d1g]

Suggestion 1 (soft warning): add glow to "Save" button when number of _changes_ (adds/edits/deletions) is over 100/200/other magic number

Suggestion 2 (aggressive warning): add glow to class "layer-layer layer-data" (main edit window in iD) over 1000/2000/... edits

http://jsfiddle.net/XUC5q/1/ - box-shadow box-shadow at mozilla docs
http://codepen.io/NobodyRocks/pen/qzfoc - random css3 variants

UX considerations:

• user(s) may be unaware that _high number of edits slows their editing process_ - they should be informed _after soft and hard warning_ that their editor is slow due to unsaved edits.
• zooming and panning vast areas without editing/commit or unloaded/purged data - may also result in slower iD - how does iD behaves in this scenario? What is suggested to end user?
• auto-commit after 3km map swipe may be an option You may also add "autocommit=yes" or "autocommit=hardwarning" or "autocommit=3kmmapswipe" or "autocommit=featurex" in changeset tags.

[SHARCRASH]

I totally agree with you guys, the more time an edit is opened, the more chances there will be for a conflict... I often end up with large edits but not because i'm a beginner. It happens when i'm trying to convert massive of interconnected areas into MP while using other existing elements, such as ways for example.
I do this because :

• it's easier to create complex areas
• it makes areas of multiple elements more clear while keeping its precision (less parallel or interconnected lines)
• it lowers data usage
• since Mapnik changed its Forest & Wood tiles with a transparency, the transparency will over tile the inner element if no relation is defined, many users plotted inner areas without relations, so now proper MP integration will be needed to be set or there will be errors in OSMi (in my home country Luxembourg, it's often near zero errors)
• last but not least, for future edits in those MP i noticed that it's way easier and less time consuming, full beneficial.

Usually I'm between 100 and 224 (today). Large number of edits because in between i do little improvements on other elements i encounter during the main area I'm working on.

I'd recommend a soft warning or a warning that someone is editing in the surroundings.

OT
Also... I got a set of prompt selections for conflicts with another user (22 in total) during a long edit (+/-224 edits if i recall correctly). Some were not for edits that happened at the same time during mine, I believe some were about the former edits that were already in place, others indeed from a user that edited the same elements in between. That's not the big issue though. After having compared all prompts in favor of mine because far more influent (positionning, MP integrations, corrections...), I encountered a second set of prompt selections (3 of them which were part of the first set), i responded again but at the saving the second set was endlessly restarting itself. Had to save the XML...

[vespax]

Soft warning would be useful. A 'glow' may not alert the user enough. Maybe a pulsating glow in the number of edits callout to give more attention the action. I would suggest a the alert have an option of 50/100/200 edits to avoid conflicts in active mapping areas.

[systemed]

If it helps, the way P2 does it is by adding a "minutes elapsed" count to the Save button (when edits have been unsaved after 5 minutes or more). Then, at 20 minutes and at 5-minute intervals thereafter, a non-modal 'floating alert' appears to say "20 minutes since last save - please save regularly".

[bhousel]

Every time I think about this issue, I think that if the save button did more and more interesting things the higher the count got, I would probably keep pushing that count as high as I could to see what would happen next.

I'm also one of those people that waits until the gas gauge is way past empty before filling the car back up with gas.

[tanerochris]

Following, from d1g suggestions, which I think is good and would love to add that ,the save button, preferably the count tooltip could glow green,transit to some other color ,and in extreme case we get an alert, asking the user to save and reasons why they should save their work.I am new to open street map and I would love to work on this given that its labeled get-started.

[bhousel]

Following, from d1g suggestions, which I think is good and would love to add that ,the save button, preferably the count tooltip could glow green,transit to some other color ,and in extreme case we get an alert, asking the user to save and reasons why they should save their work.I am new to open street map and I would love to work on this given that its labeled get-started.

Great! This is an excellent first issue to tackle..

The code to change is around here in save.js. This is a callback the updates the button state anytime the map is changed.

By default, the buttons are css background: white. Try to adjust the styling on the button and the count next to it. The current styling is determined by this css. iD uses D3.js for managing the DOM, so you'll need to understand how that works.

For now, lets keep it simple and calculate a background color that goes from #fff at 0 edits down to #ff8 at 50 edits and #f88 at 100+ edits. It'll slowly turn the button yellow, then orange, then red.

No alerts, no glows, no flashing, etc..

[bhousel]

This was merged today! Thanks @tanerochris

[tanerochris]

It is a nice start contributing to openstreet map .thanks @bhousel