Implement operating modes for user types, aircraft types and flight "modes"

MyFlightBook is very rich with features. Sometimes it is overwhelming. Consider allowing a user to select a "user type", aircraft type and "flight mode" for a given session. Then, only display those flight properties or features appropriate to the current session.

Possible user types could include VFR Pilot, IFR Pilot, CFI, ATP, Military, Club Manager, "SuperUser", etc. Aircraft types would be the standard types/categories, I assume. "Flight modes" could include aerobatic, military, IFR, training etc.

Examples:

Students can't carry passengers or collect payments (or a lot of things!)
Aerobatic maneuvering properties shown only when in on aerobatic flight mode
Glider properties only appear for use in "glider mode"
only club managers could manage a club
Only a CFI can add students or sign a flight
etc, etc, etc

MyFlightBook should remember the session profile characteristics from the previous sign-in. Because the user type is relatively constant, it could go in the user profile. Better, perhaps, would be to permit the entire "session profile" to be dynamic, and changeable at sign-in time. By changing the session profile, a pilot can use MyFlightBook in different ways according to his then-current needs.

I'm sure it's possible that a "flight mode" might have multiple characteristics, like "aerobatic helicopter" (???). So, the third drop-down should be multi-select.

I am sure completely implementing this idea across all features would be very time-consuming, take a lot of thought, add a lot of code complexity, and impact performance. However, even only partial implementation with a careful selection of the most visible and commonly used features would be helpful in making MyFlightBook easier to use and increase user productivity.

I hear where you're coming from on this, but I'm really unclear what "success" would look like. Lots of really hard challenges here, not the least of which include:

What is an appropriate taxonomy? The Venn diagrams of the different "user types" I can think of (CFI, student, airline pilot, military, ...) overlap to an astonishing degree. Club managers ARE CFIs AND private pilots AND IFR pilots AND VFR pilots, all at the same time. (other than CFI, that's me, for example, but there's a CFI in my club who does meet all of those things).
How do people know where to place themselves in this taxonomy for a given session?
when people don't see something they need, how do they figure out that they need to switch session profiles? (Or do they figure that the program just doesn't have what they need and switch to something else?)
Even if I could figure out a good taxonomy on those things, I then have to create a huge matrix with each feature and decide which features show up for which users/flights/aircraft modes, and ensure that the screens all look OK, the flows all work, etc.

I think the key thing you said here is the potential problem statement: "MyFlightBook is very rich with features. Sometimes it is overwhelming." That's potentially more actionable, but it also requires definition of what's overwhelming; otherwise, it's more of a statement of principle than an issue to address. After all, could absolutely substitute Excel, Word, Windows, iOS, MySQL, etc., for "MyFlightbook" in the sentence above and it would be just as irrefutably true.

Almost all software follows the 90/10 rule, where 90% of the people use 10% of the features (MyFlightbook is certainly no exception), so the design principle is generally to (a) make the 10% as easy to discover and use as possible, and (b) keep the 90% out of the way but discoverable as you hit the point you need it.

I think that's what you're trying to get at with the mode suggestion (keep the irrelevant stuff hidden, surface the relevant stuff) is a good one (and a principle I do try to follow!), but I confess I have a strong negative reaction to the modes, mostly because I don't think I've ever seen it work well in consumer apps before (developer apps/geeky Unix stuff targetted to tinkerer developers are the only place I can think of where it does work - and those are precisely not the audience that's "overwhelmed"). The whole notion of a mode - particularly as an up-front log-in decision - presents a whole up-front learning curve, and that's a huge barrier to usage or trial.

So I'd come back to the "sometimes it is overwhelming" part. I totally agree - where things are overwhelming, let's simplify them. Let's identify those.

But I confess that otherwise, I don't even begin to know what to do on this issue. I'd suggest we close the issue, have discussions via email about specific areas of complexity, and then create individual issues to address those specific areas and/or an overall issue for an overall site redesign, if we were to identify a model for that.

Thanks (as usual) for the thoughtful reply. Some comments in response ...

On Jan 4, 2020, at 4:07 PM, Eric Berman notifications@github.com wrote: I hear where you're coming from on this, but I'm really unclear what "success" would look like.

Sure .. at this point it’s an idea, one that needs to be developed to understand “success”. Lots of really hard challenges here, not the least of which include:

What is an appropriate taxonomy? The Venn diagrams of the different "user types" I can think of (CFI, student, airline pilot, military, ...) overlap to an astonishing degree. Club managers ARE CFIs AND private pilots AND IFR pilots AND VFR pilots, all at the same time. (other than CFI, that's me, for example, but there's a CFI in my club who does meet all of those things). I’m not so sure overlap in modes is a big problem. You needn’t define the taxonomy for this to work. Just evaluate each feature (a flight property or web-page) and see if it apples to any of those “types” (whether user, flight type or aircraft types).

The pilot “type” is just a session-specific setting. Doesn’t matter if some features appear for multiple types, as the user would be one type at a time. The drop-down I suggested would apply only to the current session. The pilot type in the profile would be a default, or there could be no default. As long as the relevant features appear when the user is in a given mode, that’s fine, even if they appear in different sessions, each in a different modes.

How do people know where to place themselves in this taxonomy for a given session? Based on what they want to do, and how they learn MyFlightBook over time. when people don't see something they need, how do they figure out that they need to switch session profiles? (Or do they figure that the program just doesn't have what they need and switch to something else?) The app’s built-in hints explain what the modes do, and users experiment. A reminder of your current “session mode” might be visible on each page, with a hint that “some features are hidden in this mode”. If the default for a session is “all pilot types, airplane types and flight types”, a user sees all features by default. Then, as they become experienced, users choose one or more of those “modes” to hide complexity. Even if I could figure out a good taxonomy on those things, I then have to create a huge matrix with each feature and decide which features show up for which users/flights/aircraft modes, and ensure that the screens all look OK, the flows all work, etc. I don’t think you need to create a huge matrix, but I do see that this is potentially a lot of work. Even just limiting this to flight properties would be a help, and the mapping from property to users/flights/aircraft modes is probably not too bad. Probably just handling properties this way doesn’t affect display of screens (because you already subset properties) nor flows. On the other hand, some subsets of features might map easily to just a single feature (and webpage).

You could limit only properties to does by enhancing the drop-down for adding "Additional properties for your flight”. Indeed, you have something of this idea in the down-arrow to the right of the prompt to add properties.

I think the key thing you said here is the potential problem statement: "MyFlightBook is very rich with features. Sometimes it is overwhelming." That's potentially more actionable, but it also requires definition of what's overwhelming; otherwise, it's more of a statement of principle than an issue to address. After all, could absolutely substitute Excel, Word, Windows, iOS, MySQL, etc., for "MyFlightbook" in the sentence above and it would be just as irrefutably true.

No doubt. Ok, the list of properties is definitely overwhelming.
Almost all software follows the 90/10 rule, where 90% of the people use 10% of the features (MyFlightbook is certainly no exception), so the design principle is generally to (a) make the 10% as easy to discover and use as possible, and (b) keep the 90% out of the way but discoverable as you hit the point you need it.

Agreed. That’s consistent with the idea of only showing those properties (or features) applicable to how I want to use MyFlightBook at the moment. There are certainly examples of programs (maybe fewer websites) that have “Beginner” or “Advanced” mode. Sometimes this is just for a particular sub-feature or given dialog box (like the network preferences for MacOs), but sometimes for the entire product for a given session.

I think that's what you're trying to get at with the mode suggestion (keep the irrelevant stuff hidden, surface the relevant stuff) is a good one (and a principle I do try to follow!),

Right. but I confess I have a strong negative reaction to the modes, mostly because I don't think I've ever seen it work well in consumer apps before (developer apps/geeky Unix stuff targetted to tinkerer developers are the only place I can think of where it does work - and those are precisely not the audience that's "overwhelmed”).

On the other hand, exposing a ton of “geeky” stuff to normal consumers isn’t great either. Perhaps surprisingly to you, since you worked on Excel, Microsoft Office in fact has “Application Modes”. https://docs.microsoft.com/en-us/windows/win32/windowsribbon/ribbon-applicationmodes Some of that is just dynamic and contextual based on the current usage. Some is by explicit user action to “Switch to simple mode” or “Switch to advanced mode”. Microsoft Word allows you, under Preferences, to turn off specific features.

I believe I’ve used a product that allows me to turn off entire menus. I’ve seen similar concepts elsewhere, iOS and macOS Settings in particular, but nothing else comes to mind at the moment.

The whole notion of a mode - particularly as an up-front log-in decision - presents a whole up-front learning curve, and that's a huge barrier to usage or trial.

I see your point, but if the default mode is “all”, then the learning curve only comes if you try entering a certain mode. The ability to choose a “session mode” could be under the sign-in pop-up you’ve just created: “Enter simple mode”. So I'd come back to the "sometimes it is overwhelming" part. I totally agree - where things are overwhelming, let's simplify them. Let's identify those.

Again, properties. However, as a still relatively new student pilot, I really didn’t want to learn about flying clubs, nor would I want to (be able to) add students, etc. With some time, I expect I’d find other examples. The implementation of this concept could be progressive, not done all at once. But I confess that otherwise, I don't even begin to know what to do on this issue. I'd suggest we close the issue, have discussions via email about specific areas of complexity, and then create individual issues to address those specific areas and/or an overall issue for an overall site redesign, if we were to identify a model for that.

I do think it makes some sense to noodle on a strategy for overall simplification, before getting buried in the details of each specific feature. Having an overall approach, whether this one or another, and then working to fit simplifications into that strategy is likely to be more comprehensive and successful in the end. Aside from this comment and this email, I agree with your suggestion to take this discussion offline. I’ll try to think about it more ... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/441?email_source=notifications&email_token=AEBRDEFCRBKLAIYBKAFKRBLQ4EJETA5CNFSM4KCR6YHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDCHGI#issuecomment-570827673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBRDEAWDVHWU7YDWRO2DWLQ4EJETANCNFSM4KCR6YHA.

For properties, that's exactly why I implemented templates. See my blog post for how these work - they are a lot like overlapping modes, but within the (admittedly!) overwhelming world of properties. I think that's the place where the "overwhelm" is most real. Templates are something that don't get in your way - you can use the product quite well without them - but when you discover them can help manage things. I'd love any thoughts you have about how to further simplify properties or manage the sheer number (673 properties available, currently!) of them. "Previously Used" is one simple automatic way (which I do), and templates can expand on that - but templates are a form a mode, where you have to encounter the problem to realize that it's a problem and ask if there's a solution to it.

I think a taxonomy does have to be largely segregated, otherwise it's not adding much value - after all, if "CFI" and "IFR Pilot" (to make up two modes) are 90% overlap, then the overhead of switching modes will outweigh the optimization of one mode or the other. Sure, a feature can be in multiple "modes" (that's what the taxonomy defines), but if a lot of features are available across a lot of modes, then the modes themselves become hardly distinguishable.

I remember working at Microsoft on things that had a junior mode or a simple mode. We stopped doing them because people just didn't use them - it didn't help the novice (because they didn't know about the whole mode thing in the first place) and it didn't help the non-novice because, well, they didn't need the simple mode. The Application modes thing is actually just an advanced customization. Customization is fine - I don't have any problem with that as functionality - but that's not quite the same as a mode. That's actually a deeper optimization for your task.

For now, to reduce "being overwhelmed" by issues (grin), I'm going to close this particular one. While I do want to track feature ideas, I want to be careful of a whole lot of blue-sky back-and-forth stuff crowding out actual bugs and other block-and-tackle features that I need to get to...

ericberman / MyFlightbookWeb

Implement operating modes for user types, aircraft types and flight "modes" #441