Replies: 7 comments 5 replies
-
|
I think it is a great idea to discuss this. We should put it on today's agenda IMHO. My personal point of view: I am also not personally intrigued by complex GUIs which "normal" users may find ugly or non-understandable. However, I deeply respect and understand the wishes of others to have that. I also grant that c:geo is in a terrible state UX-wise. Thus I am open and willing to follow any concept or rules we give ourselves as a team. I am also willing to work migrate existing stuff to such a concept. Where I can only be of little to no help however is creating such a concept. What is important to me: same rules for all. If a new feature shall be introduced same GUI rules apply to and are enforced for everything. Regardless of personal feature preferences. |
Beta Was this translation helpful? Give feedback.
-
|
One rather technical idea to approach at least the problem of ridicuously long options menus: implement generic settings to let users customize which options they want to see where and which not. Look & Feel could be very similar to the already introduced "quick launch button" settings: But for ALL option menues, e.g.
This only solves part of the problem, but could be a bridge between "power users" needing very specific functions and "normal users" only needing base functions. It could also provide a means for "normal users" to become "power users" over time |
Beta Was this translation helpful? Give feedback.
-
I don't like the idea of treating users as "normal" or "power users" because I don't think those distinctions really exist. At least not how we developers think of them ;) Even though I might use more advanced features, I still prefer a simple UI. It seems like saying "let's do it for power users" is just a way to avoid designing a carefully planned UI. Putting features in "advanced options" might work temporarily, but it's not a real solution. |
Beta Was this translation helpful? Give feedback.
-
|
My first thought upon reading that was: https://xkcd.com/927/ "Let's add more settings to our too-many settings to make it less setting" Making the UI user-configurable is a great feature - for die-hard power users. It's basically what I'm doing with my custom builds, just a tad more accessible. But it's something that only very knowledgable users will use.
Leaving it up to the user is the "the dev's who know the application best couldn't decide on what's important, so now they push the decision to the user who just wants to use the app". |
Beta Was this translation helpful? Give feedback.
-
|
I think "remove features" is wrong approach to the problems cgeo has. The value of c:geo is that it has many features. The problem it has is not the feature count but the complexity of the UI. These 2 points are related, but far from identical. Let me try to explain with a simplified example: A flashlight app. This app has only 1 feature. The simple UI will have 1 big button: On/Off. Yet even such a simple app could have a complex UI, e.g. you could have a slider for brightness, a timer for auto-off, different blinking modes, color wheel, share to facebook when the app is used, ... Now unfortunately for us c:geo is far from a flashlight app. What's even worse - and this makes the situation pretty much impossible to resolve without causing pain - is that it's been complex for a very long time. This lead to people using c:geo in very different way - because it allows those degrees of freedom. So even trying to identify the core values of the app is a quite hard endavour - ask 4 people and you'll get 5 answers. With that said let me come back to the original "remove features": I'm absolutely certain that there's not a single feature in c:geo that can be removed without upsetting a considerable part of the userbase - those users for whom that feature that's not relevant to you is very relevant for in their workflow. So what can we do? Imho we should not do nothing, we should try to improve. But doing that we must try to minimize pains - and that to me means we shouldn't touch the feature set (because again, that's what makes c:geo so great - sorry, another interlude here: I know many people who years ago didn't use c:geo because it was laking many essential features. They used e.g. Locus instead. And just today one of those former "Locus for Geocaching"-users told me that c:geo now has every feature he needs for geocaching + everything he needs for hiking, so he doesn't even need "Locus for Hiking" anymore. So all those features are certainly delivering value! - now back to the point:) What would be needed to follow this approach? I don't think there's any way to avoid the classical product development workflow here (and hey, that workflow is established industry standard for a reason!): Gather data on how people use the app, what problems they try to solve (= collect requirements, write user stories), which features they use for that, suggest them alternatives (= evaluate approaches and refine them). That's a huge amount of effort for sure - and considering the wide range of c:geo users to do it proper we'd have to look at every story with at least several people. And what's for sure: This can not be done in text form in a forum! All what I said above is on a meta-level, because putting that in practice is a quite big challenge - for every single feature! But let me try it with one specific example - routing - because we had that discussion in the other thread. What's the usecases (that I can think of right now - this is where more perspectives are needed):
So it seems we need at least "add navigation target", "add Xth target", "set navigation mode (as the crow flies, hiking, biking, car, ...)"
Let's assume my list of usecases/requirements and my derivates above were complete I now make some conclusions (based on cgeos existing UI, because trying to make this exercise with a green-field approach is just too much for a Sunday afternoon):
After writing this quite long text I realize even more than before: Text is not a suitable format for this! So I'm ending this comment here, even though it's certainly not perfect, many nuances are missing, but I hope my general perspective on this comes accross. |
Beta Was this translation helpful? Give feedback.
-
|
Just thought of another example that I find very fitting to describe c:geos current problems. The above discussed problem was "there are too many buttons" - but that's not all the problem there is. Sometimes using c:geo is just very very complicated!! Requirement: I'm looking at a map of caches and want to find the optimal route to visit them all. Current solution (the best I know):
That's a total of 15 taps! |
Beta Was this translation helpful? Give feedback.
-
|
Just remove enough to get UI clean was a pretty stupid idea from my side, so I'm glad you turned that topic into a really valuable discussion. Well written and I agree with pretty much all you've said. Personally I have to say that I don't like apps doing too much magic in the background, but I definitely agree that we should focus more on usecases and workflows instead of just adding features without thinking about how they are used. |
Beta Was this translation helpful? Give feedback.
-
The stuff I removed is certainly not something that could go into c:geo, I'm listing it here because it was brought up:
|
Beta Was this translation helpful? Give feedback.
-
Just because you asked: this is immensely useful if you want to log a premium cache for a secondary basic user going caching with you (e.g. your child with his/her own basic account). Because stupid gc.com does not allow that user to access the details page but just the logging page directly. |
Beta Was this translation helpful? Give feedback.
-
|
So it's only relevant if 3 conditions are true: Logged-in user is Premium (edit: not true - it might also be a Basic user who got the GPX) + Cache is PMO + user is interested in log-link for basic users. The first are easy to check (and right now they are not) -> already the menu item will be gone in ~80% of cases -> #15442 |
Beta Was this translation helpful? Give feedback.
-
|
While I understand the "technical approach" discussed further up, this won't help most users, IMHO - they would need to check long lists with menu entries to activate/deactivate, while they don't understand the meaning for many of them, probably don't even know where the specific menu is located. To my understanding, this approach is more suited for the very experienced user that knows most of the options by heart. Let me scribble down a different approach (that somehow builds upon this idea) - that's what I have pitched briefly in our last dev call: Instead of enabling/disabling menu items per one-by-one, do enable/disable larger functional blocks (and for this not only menu items, but other related visual elements as well). I can imagine not more than a handful of switches, each of which enables a certain portion of c:geo, some functionality across the whole of the app. "I never use routing" was an example mentioned in one of the discussions. So let's imagine, this would be one of those switches. If disabled, a couple of things would be hidden from the user, eg.:
If this includes "internal routing" as well, more items could be hidden:
If this includes all routing options, even more would be hidden: (though I would not go thus far):
This is just an example, and probably incomplete. The story behind this example would be: "How would c:geo look, if it had no routing functionality" (or whatever functional block you want to exclude). "Disclaimer": Don't know, though, if this approach would actually work in general, if it removes enough visual clutter, and if we were able to identify a handful of large-enough blocks (and could agree on them). Our use-cases (and those of our users) may be too diverse to find a good solution. |
Beta Was this translation helpful? Give feedback.
-
|
I have no time currently to in deep follow the discussion but I still want to provide my personal view: IMHO we might have some different categories of problems with the feature set in c:geo:
In general removing existing and released features (without a similar replacement) is problematic as users might rely on them. This feature split should be as easy as possible (meaning: Better a simple switch than another setting menu where users can decide what feature to activate). |
Beta Was this translation helpful? Give feedback.
-
In #15425 @eddiemuc mentioned that routing GUI is too heavy-weighted, and that we should take steps to clean up the GUI in general. @ztNFny is privately using a "cleaned up" version of c:geo. And for my side, I honestly gave up c:geo's UI completely. Depending on my current mood, I either argue against new features or just let it happen.
Keep in mind:
We are power users. Almost nobody knows c:geo better than we do, and yet even we feel overwhelmed by using it.
I want to use this discussion to collect features which clutter c:geo's UI too much and can be removed or placed in a more streamlined way.
Somehow related:
Already quite some time ago I wrote down some UI conventions, however they were not yet discussed by the team. I don't know if they currently make sense and follow the c:geo's philosophy, but maybe we can write down some guidelines we all agree with in one of the next team meetings.
Beta Was this translation helpful? Give feedback.
All reactions