Closed sonora closed 2 years ago
I'm gonna chime in here to encourage you guys. This is very much needed, but as someone who is using the nightlies as daily driver, I have to say that I am very impressed with the work you guys are doing right now. I see the UI growing and getting better every time I update. The automatic, big 'download current area' for example is a great addition.
So, go for it!
Well it will take a lot of effort to consolidate, it looks like it is easy but it is not easy at all. There are so many screens and functionality that even checking all fonts / sizes took us 2 weeks. Changing user interaction and consolidating is even more complex task.
What I can say for sure, that My Places and especially My tracks going to be refactored by another reason. We're going to enable plugins that can add new functionality to tracks etc, so we need redesign how we: 1) select items 2) search items 3) perform single action over item 4) perform batch action over items 5) provide generic statistics over group of items
I really hope to address it in 2019. Though it has at least 6 group of items: Favorites, Markers, Tracks, AV Notes, OSM Edits, Avoid roads (?)
I guess we could slice the elephant before eating it ... :)
The basis would be to define a sort of standard style or style guide, it would suffice to pick one selection screen and/or one settings screen as our model. Then all developers could successively work on evolving other screens accordingly as they see fit, have time, or touch them by working on related funcionality anyway. In this fashion it does not need to be a huge dedicated activity?
As a UI-UX designer I find OSMAND navigation specifically painful, confusing and inconsistent. Lots of part behave, look and feel like designed by engineers. Design systems are popping up everywhere and OSMAND would benefit from one considerably. You don't have to refactor whole system at once but it could be done step-by-step over longer period of time following a UI.UX roadmap.
+1 to this, would like to see this
As a UI-UX designer [...]
Since you are a UI-UX designer maybe you can provide some specific suggestions for UI improvements? This would be really helpful.
Linking an open issue about the menu structure https://github.com/osmandapp/OsmAnd/issues/10244, because I think this also falls into the same category of UX improvement.
settings / menu strucuture discussion is also here: https://github.com/osmandapp/OsmAnd/issues/9047
regarding navigation: multiple users I brought to OsmAnd were not able to find how to stop a running navigation (click in the map, click the blue navigation arrow, click on "Dismiss", "Are you sure" -> "yes").
Another thing that caused confusion was that you can choose different profiles for navigation and display of the map. So while navigation you might e.g. see a car icon in the top left of the map, but actually doing pedestrian navigation.
The thing that still confuses me is the difference between "configure map" and "configure screen". When I am on it I more or less understand the difference but I find myself always thinking 3 times which I need to click and maybe still end up with the wrong one.
Whole OSMAND UI navigation needs restructuring. Best would be start from card sorting. Pretty low level, simple and always reliable.
@macintoshee which card sorting are you referring to? Would you mind providing some simplistic mockups?
Card sorting as methodology. Research tool for building better UI. We need UI/UX research plan or UI/UX research project. Either way I'm not up to it til late autumn or early winter.
https://www.usability.gov/how-to-and-tools/methods/card-sorting.html
Usability resources:
The thing that still confuses me is the difference between "configure map" and "configure screen".
This may be a case of terminology. Although I'm unlikely the imagined audience, less-ambiguous synonyms which come to mind are
However, these terms won't be familiar to non-technical users.
I imagine @NotSoImportant's confusion stems from them both being different aspects of what's displayed.
This alludes to these being a mismatch between the mental-model of how OsmAnd works, and how OsmAnd proper actually functions & behaves. That's likely down to something lacking in how OsmAnd communicates (non-verbally, via cues) such concepts to users.
@scaidermern
Since you are a UI-UX designer maybe you can provide some specific suggestions for UI improvements? This would be really helpful.
While I understand where this comes from, it's not quite that simple, unfortunately. What makes for good usability is often (if not always) highly dependent on context & intended audience (target user-group).
Just like with technical considerations, decisions about UX often come down to trade-offs.
The only consistent advice would be principles & guidelines. How to apply them is usually different for each context, for a variety of reasons.
Compare asking for specific advice about making a killer app, or designing & implementing quality software. It depends on a whole lot of factors. There are entire sections of libraries filled with books trying to address that. Same with interaction-design (and even more so with design in the broader sense).
A better (technical) analogy might be security; what's good or bad practice very much depends on the context, what you're trying to protect, and the threat-model.
For an illustrative example of applying principles to a specific context (or at least trying to), have a read of openstreetmap/iD#8590.
Once one groks the principles & mindset, it becomes much easier to know what specifics might be sensible.
However, in all this, always be mindful that developers are not the target audience (by nature / disposition, and because they're already intimately familiar with the software). So proper user-testing is vital to guide & prioritise refinements. Otherwise it's guesswork.
card sorting
While that's a useful & effective tool, I would argue that it's more for when fundamentals are already known, such as for prioritising work.
Another, to help figure out what might be needed (as part of proper user-testing; see above), is paper-prototyping.
Since cross-referencing didn't happen automatically (🤷♂️); another scenario which would benefit from some interaction-design attention: #11846.
I think it is about tine we unify our look and feel a bit across the app. The way we have it now we e.g. use different mechanisms to leave screens: Sometimes you just have to tap the device's back button to leave a screen and changes will be remembered (e.g. Configure screen and Configure map). On others we use a Dismiss button, e.g. under Map mode. Yet on others you have to explicitly Apply or Cancel a configuration , e.g. under Map style. Under Configure maps/GPX files we use explicit Cancel or Ok. On yet other screens we have 'Leave' arrows top left, or a confirmation check mark top right.
Also, on the latter screen we use tick boxes to make tracks visible, while we mostly use sliding switches for similar functionality elsewhere.
Our screen My places / Tracks uses sliders for already visible tracks, but no visibility selection mechanism at all for not yet selected tracks. Instead you have to either tap on a track's name then chose actions on the subsequent screen, or select a track's 3 dots menu, which in turn offers all sorts of actions but is missing the very one that gets you to the screen you would reach when tapping the track name.
All this grew historically in recent years, via different designers and developers. I suggest here we now apply some overall product managment and governance to put OsmAnd in the league of a managed product with a distinct, uniformly applied, ergonomic look and feel, and not just a collection of dozens of functionality and options screens all working slightly or even notably different.