Include Menu items (UI) for features that require manual action

[mtlynch]

We have several network operations that I eventually want to integrate in the web GUI, but they're currently things you have to perform manually with SSH.

• Set a static IP
• Enable WiFI
• Specify an HTTP proxy (coming soon)

It would be good to help the user discover that those features are available even if we don't yet have a smooth web UI for managing them.

The challenge here is to balance competing forces:

• We want to make TinyPilot's functionality discoverable
• We don't want to clutter the UI by mixing features that work as expected and features that feel half-baked and tell the user to go do it themselves on the command-line

Is there a way to achieve this? Some potential ideas:

• Add a menu item like "Manual features" that has dropdowns to the things that require the user to do it manually
• Add a tag like "alpha" or "experimental" to the menu item to convey that it's still in progress

[jotaen4tinypilot]

I’ve been thinking about this, and I’m happy to work on a proposal here. I have a few points, though, that I’d like to discuss:

Instructions

How exactly do we want to make the instructions available? Since they are manual features, they are not just a simple toggle button, but we rather need to outline the steps that the user needs to go through in prose.

• We could embed the instruction texts into the UI, e.g. into a dialog.
  • That might be very convenient for the user, since they’d be right there. Also, the instructions might be specific to the installed TinyPilot version, so it’s easier for us to account for that if they live in the tinypilot repository.
  • On the other hand, we wouldn’t be able to easily update the instructions. E.g., if we – at a later point – notice that they contain bugs, or if we feel that they lack clarity, we wouldn’t be able to make changes after the fact.
• We could link to instructions pages on tinypilotkvm.com.
  • The benefit is that we have full control over the texts, and can update them at any point.
  • On the other hand, we would need to find a way to account for invariants of different versions. In the easiest case, we could pass a URL query parameter like ?fromVersion=17a298c or the like, just so that we’d be able to respond to a potential invariant if need be.
  • Another thing would be whether we need to provide the beta instructions forever, since it might happen that a user is still on an ancient version, even though the then-beta feature had long been released for real in the meantime. On the one hand, we could be so kind to preserve old instructions; on the other hand, we could take that opportunity and tell users “this is a real feature now, please just update your device”.

Menu

Update In the meantime, we already launched the “Help” menu, so things are a bit different now compared to when I originally wrote this.

I’m really not sure we should just add another item to the “System” menu. To me, it feels like we are on the edge of treating the “System” menu as general-purpose bucket for all kinds of different things. Actually, the “System” menu is for managing the system state of the TinyPilot device. Items like “Virtual Media” or “Video Settings” fit that definition perfectly. However, items like “About”, “Logs”, or “Beta Features” don’t really feel as strongly related, since they are mostly informational, and also more special-purpose and subsidiary / “auxiliary”.

Apart from that, the “System” menu contains up to 9 items in TinyPilot Pro right now (including the conditional “Log Out” item), which to me is too much for it to be easily graspable. To me, 7 would be a sensible maximum, so having 10 is really quite a lot for a single menu.

Therefore, I think that we should use this opportunity to revisit the menu structure (of the “System” menu mainly), in order to properly account for the growing number of items and their different character. It would make sense to me to work on that in parallel, because I see cross-cutting concerns with whatever we do here.

Discoverability

Similar to what I already suggested in regards to system updates, we could consider to actively draw the user’s attention to a new beta feature after they performed a system update. So if the new TinyPilot version comes with a newly available beta-feature, we could show an indicator to make the user aware of the additional functionality. Since not all users might be interested in beta-features, such a notification mechanism could be opt-in.

On the other hand, the issue of discoverability of new features is not specific to beta-features. We already have a link to the changelog in the “Update” dialog, but that’s quite subtle, and also only available before users carry out the update. But once the update is done, and the new system is in place, the changelog link is gone too.

[mtlynch]

Sorry for the delay on this! It's been a busy couple of weeks, but this is still on my radar to review.

[jdeanwallace]

@mtlynch - Just checking to see if this is still on your radar to review?

[mtlynch]

Yep, still on my radar. Just haven't had availability.

[jotaen4tinypilot]

I wanted to give this a gentle ping again 😅 Depending on when we’d want to release this, we might need some prior thinking/concept time before we can implement something. (The ticket is currently prioritized quite late in 2.6.0.) I think this could generally be a good ticket to keep working on “on the side”, rather than trying to tackle it in one single, concerted effort from start to finish.

[jotaen4tinypilot]

That being said, I’m not emotional about this feature, but we keep pushing it back for some reason, and I’m wondering whether this has something to do with actual priority, or maybe with our approach to it.

[mtlynch]

Sorry, this keeps reaching the top of my to-do list and I think, "Oh, I'm going to have to think hard about this, but it's not urgent," and I keep pushing it.

Instructions

How exactly do we want to make the instructions available?

I think linking out to the FAQ is the best option. I'd like to have it be in a place where we can continuously update it. The ?version query parameter is a good idea, and we should do that since it's easy to do and gives us flexibility in the future.

Another thing would be whether we need to provide the beta instructions forever, since it might happen that a user is still on an ancient version, even though the then-beta feature had long been released for real in the meantime. On the one hand, we could be so kind to preserve old instructions; on the other hand, we could take that opportunity and tell users “this is a real feature now, please just update your device”.

I'm not too worried about this. It's pretty easy for us to just update the text to say "Update your device" and then archive the FAQ page so it doesn't show up in the FAQ index.

Therefore, I think that we should use this opportunity to revisit the menu structure (of the “System” menu mainly), in order to properly account for the growing number of items and their different character. It would make sense to me to work on that in parallel, because I see cross-cutting concerns with whatever we do here.

I agree, but we also want to minimize churn. If we, for example, moved "Logs" to a different heading, then we suddenly have dozens of support forum posts that become incorrect for future versions.

we could consider to actively draw the user’s attention to a new beta feature after they performed a system update. So if the new TinyPilot version comes with a newly available beta-feature, we could show an indicator to make the user aware of the additional functionality. Since not all users might be interested in beta-features, such a notification mechanism could be opt-in.

I wouldn't call these beta features exactly because that implies that we're planning to polish them, and we're just sharing an early draft. But for some of these features, we just added manual instructions because a few users asked, but they're not worth the implementation cost / maintenance burden of building a web UI for them.

I feel like if we present them as "here are some exciting new beta features!" the user will expect that we're on the road to making them first-class features. Maybe it's a distinction between "highlighting" the feature and just making it discoverable. Because I think our goal is to make it discoverable rather than generating excitement. We just want to prevent a user from discovering through some other means that a static IP is technically possible, and then they think, "Why didn't TinyPilot tell me I could do that?"

[shalver-tp]

@jotaen4tinypilot Re-opening this in general, but also for implementation of some potential new menu items.

Enable/Disable Read-Only Filesystem

[shalver-tp]

Some of the thinking on this issue is potentially outdated, so I will just try to recap and reset a bit.

For the most part, we do not want to change the location of anything if we can avoid it. We also do not want to add more menus, nor do we want to add more items to an individual menu - but there are some items that we want to integrate as a key part of the product and as such they need a menu item.

Current Menus

The 2.6.3 Menu Tree

• System - settings for the TinyPilot device's system
  • Security - opens popup for Web Access, SSH Access, and require HTTPS
  • Virtual Media - opens popup for managing virtual media
  • Update - opens popup and checks for updates
  • Networking
    • Hostname - allows you to change the hostname of device
    • Static IP - allows you to set a static IP for device
  • Video Settings - opens popup to change video stream settings
  • Logs - opens popup with log information
  • Power - opens popup with options to shut down or restart
• Actions - this is actually very well described, these are actions that the user can launch
  • Paste - opens popup and allows you to paste text to send to your target computer
  • Screenshot - takes and saves a screenshot of the target computer
  • Wake on LAN - opens a popup to allow you to send a WOL signal to another device on the network
  • Keyboard Shortcuts
    • Ctrl Alt Del - allows you to send Ctrl Alt Del to the target computer
• View - options for how you view TinyPilot
  • Cursor - options for customizing the appearance of your cursor
    • Default
    • None
    • Crosshair
    • Pointer
  • Show Keyboard - Check on or off to show or hide on-screen keyboard
  • Enable Key History - Check on or off to enable key history
  • Full Screen - when selected, your target computer goes Full Screen
  • Dedicated Window - when selected your target computer pops out into a different window
• Help
  • About - popup that provides version, license, and privacy information
  • Technical Support - pops out a browser tab for tinypilotkvm.com/contact/
  • FAQ - pop outs a browser tab for tinypilotkvm.com/faq

New Menu Items

There are a number of items that currently require a code snippet (or similar) to enable but have enough frequency in customer support interactions or are a new "feature" that we should try to surface them from a menu.

• Configure Wi-Fi
• Launch Console
• Mouse Jiggler
• Enable/Disable Read-Only Filesystem

Configure Wi-Fi - This can go under System -> Networking -> (below Static IP)

FAQ, Related Issue: 131

Launch Console - This can go under Actions (below Wake on LAN)

Related Issue: 1332

Mouse Jiggler - This can go under Actions (below Launch Console)

FAQ

Enable/Disable Read-Only Filesystem - This can go in System -> (below Update)

FAQ, Related Issue: 1331

[jotaen4tinypilot]

I had a few more thoughts around this, which I wanted to share for discussion. What I was wondering about is what the mechanics of these “advanced” features would be, especially compared to our “regular” features and menu items.

Disclaimer: all mock-ups below are not meant as final proposal, but rather as rough draft to get the basic idea across.

For example, would we want to layout the menu items in a slightly different way, to help users distinguish them from “conventional” and fully polished end-user features, and potentially to manage expectations? Or do these “advanced” menu items just sit side by side with the existing ones, essentially being “first-class features”.

(The label “exp” is short for “experimental”, which is probably rather terrible of a name.)

Another question would be what the menu action would be:

• We could open a regular dialog, which either contains the instructions, or which contains a link to the instructions on tinypilotkvm.com.
  • The latter would have the advantage that we can update and clarify these instructions at any time, whereas the downside is that the flow would feel more “detached” for users.
• If we want to link to remote instructions, we could also consider sparing the dialog and opening the link right from the menu.
  • We already have that UI, e.g. in the “Help” menu, so users should be familiar with it.

If we wanted to go with dialogs, we could also apply the same idea, where the dialog has a slightly different appearance than the regular ones, similar to how we do it with error dialogs. That might help the user understand that they are in “advanced”-land.

(The dialog below has a purple-ish background tint, and a purple top bar.)

[cghague]

I'd like to jump in and offer a possible solution for how we could implement this. My suggestion is to add a "Show prototype features" checkbox to the "Security" dialog that enables these features, similar to how you can turn on additional menu options in Safari or how you can "become a developer" on Android.

The benefit of this approach is that we can still make these features available in the user interface while making it clear that they are not intended for novice users. We can also avoid having the default menus cluttered with "experimental" options that might look unprofessional or alarming.

[shalver-tp]

Thanks for the discussion @cghague and @jotaen4tinypilot

My goal is for these features to NOT be experimental, but table stakes as the product evolves and matures.

I realize that the initial discussion in this issue was around "experimental" features - I didn't intend for these to still feel experimental.

An example of how this might work with Wi-Fi:

• It shows up in the menu as seen above (no special mark).
• It opens a dialog box to configure wi-fi settings.
• The system checks if SSH is enabled, if so, proceed to enter wi-fi info via UI
• If SSH is not enabled, the dialog box mentions you need to enable SSH to proceed (then provide a switch for SSH in that dialog box, and the disclaimer language)
• Then run the SSH check again and provide the space to enter wi-fi info via UI

I apologize if this was unclear by hijacking this older issue.

The one "new" action I've listed that I am unsure about "exposing" is the read-only filesystem. I completely understand the logic around making it easier for support issues, but it does "reduce features" by locking out network changes.

Perhaps we nix the Read-Only Filesystem selection. It feels like having them reduce features to make the system work better does not make this seem like a "premium" product (and that is how we should be seen - we've got the best software and hardware!).

After talking with @db39 , I have a better understanding of the Read-Only Filesystem selection. I think it is a valuable menu item if we can execute it.

Thanks for further thinking and discussion!

[jotaen4tinypilot]

@shalver-tp seeing that we have dedicated tickets now for configuring WiFi, launching the console and toggling the read-only file system, I’m wondering whether this ticket here might have become obsolete? Or do e.g. want to do any sort of groundwork beforehand that would affect all three of those tasks?

[shalver-tp]

@jotaen4tinypilot I think this ticket is potentially obsolete, the only thing worth preserving or linking to might be the discussion beginning from this comment. https://github.com/tiny-pilot/tinypilot/issues/1106#issuecomment-2121528254

[jotaen4tinypilot]

Ok, alright! I tentatively have set the ticket status to “on hold” for the time being, to clarify that it’s not actionable at the moment. We could otherwise also close it at some point.