[FR] Rework UI menu structure

[Sebazzz]

The current UI menu structure - we inherited this from Creality - is quite unlogical and I often find myself lost when using the printer. We need to clean this up. I don't think the default MarlinUI is the best way to do it - we can do better than that.

Current UI:

• Print
  • Print confirmation
  • Print progress
  • Print finished
• Prepare
  • Move
  • Filament extrude
  • Disable steppers
  • Preheat PLA
  • Preheat PETG
  • Cooldown
• Control
  • Temperature
    • Nozzle temp
    • Bed temp
    • Fan
    • PID tuning (conceptually for [FR] perform PID tuning directly from printer #60)
    • Preheat PLA & PETG settings (huh!)
  • LED
  • Screen stand-by
  • Screen stand-by brightness
  • Sound
  • E-steps (conceptually for [FR] configure e-steps directly from printer #57)
  • Restore factory settings
  • Info / about
• Leveling
  • Set Z-offset
  • Auto bed leveling

I think a new menu structure would be leaning on four pillars:

• Print preparation
• Printing
• Settings
• Calibration

The menu structure would be something like this for:

Calibration

• PID [FR] perform PID tuning directly from printer #60
• E-steps [FR] configure e-steps directly from printer #57
• Leveling
• (perhaps advanced steps/mm settings in the future)
• Reset to factory settings

Settings

• Temperature
  • Preheat PLA/PETG/ABS settings
• Screen settings
  • Standby / brightness / standby time / sound
• Probing
  • Perhaps future settings for Make preheat timeout and pause while printing heater timeout user configurable #116 and [FR] Make "Heaters off when probing" user-configurable #106
• LED
• Reset to factory settings (this is duplicate with calibration but I don't think that is an issue)
• Info / about

Print preparation

• Move
• Temperature
  • Preheat PLA/PETG/ABS
  • Hot-end / bed temps
  • Fan (is this actually necessary?)
• Load / unload filament
• Disable steppers
• Cooldown

[Allan-N]

Re: Print preparation / Temperature / Fan

There are places where some might want fan control. For example, when PID tuning one might want to have the fan on ... at a certain speed ... so that the tuning results will reflect the operational environment.

Whether that is "Print preparation" is certainly debatable.

[Beeble2695]

For the new menu order:

Print preparation
-Isn't cooldown better suited in the temperature submenu?
-Fans are part of temperature control, for me it makes sense being placed there.
-Move and disable steppers share the same category as well

Could maybe expand on the LED settings too, must be some additional functionality to be added such as "turn off LED when print is finished"

[Thinkersbluff]

Use Case Analysis Example (WIP).pdf
I keep thinking it would help to separate WHAT we want to do through the interface from HOW we want that to work.
In the "olden days", we used abstractions like "Users"/"Actors" and "Use Cases" to identify all of the contexts within which the UI would be needed and - by extension - the UI features that would be required. Discussing the Use Case details helped expose the implicit thinking that caused designers to propose/champion ideas which others found strange.

This is not a warship or a rocket, so the process may seem overly heavy for this exercise, but I think the principles are still valid and you may have a lighter equivalent methodology into which you might transfer any good ideas herein:

My first-cut at the "User"/"Actor" list would likely include:

1. The Maker (you and me, when we print something)
2. The Maintainer (you and me, when we calibrate the printer for optimal performance.)
3. The Host (Octoprint, Pronterface, Cura, etc., controlling and monitoring the printer via the serial interface, and possibly distracting our Actors with their own interpretations of events & conditions)
4. The Motherboard Firmware (which needs to exchange info with the printer, the Display and the Host )
5. The Display Firmware (which needs to exchange info with the Motherboard and with the User)
6. The Printer (which interacts with the Maker/Maintainer/Motherboard and Environment)
7. The Environment (the "hidden" actor, which interacts with all of the other actors in ways that we sometimes forget...)

For the purposes of keeping this exercise reasonably simple, I imagine we expect to remain focused primarily on the first two actors, but I think it will help validate the structure if we cannot think of a problem with it when we occasionally scan down the rest of the Actors list.

If "Pillars" are to be the basis for the UI structure, maybe it helps to correlate the "Pillars" with the "Use Cases".

Since calibrating the esteps typically involves printing something (like a calibration cube), there may be some overlap between Use Cases at first. We could finesse that on subsequent "passes" by "slicing" the Use Cases into procedural building blocks, which are then chained into Use Case Workflows. Or we can try to skip a step and define an intuitively obvious set of building blocks based on our collective experience. Higher risk of bias-induced blindness but faster results. ("Fail quickly, fail often.")

If we define the "Pillars" to be the procedural building blocks, we can imagine Actors 1 & 2 each trying to build their Use Case workflow(s) by "chaining" those blocks together in whatever sequence minimizes the number of blocks (equivalent to menu-changes) to execute their workflow. (Assumes the fewer menu changes the better, to complete a procedure.)

e.g.: My first-cut at the Maker's Use Cases would be:

1. Prepare the printer for printing a particular model with a particular filament (e.g. Clean bed, apply adhesion helper, Home, Load Filament, enable Power Loss Recovery, etc..)
2. Prepare the model for submission to the printer (e.g. Select model, Slice Model, Load onto SD card or Submit to Host, depending on the Maker's preference.)
3. Start a new print, using an SD Card
4. Start a new print, from a Host
5. Monitor an ongoing print - recognize any event/situation requiring operator intervention
6. Actively intervene in the case of one or more events/situations requiring operator intervention
7. Tune the printing parameters during a print
8. Pause an active print
9. Tune the printing parameters while a print is paused
10. Resume a paused print
11. Change filament during a print
12. Abort/Cancel a print

NOTES:

1. Use Cases 6 & 7 will require elaboration for each condition/event that the UI design attempts to expose or support intervention, especially SAFETY-related events like Thermal Runaway.
2. A list of Use Cases like the one above could also form the outline of a regression/release test plan, to ensure the scope of the test coverage is consistent at each release & to provide a logical framework into which all relevant user feedback and issues resolution knowledge can be preserved.

I recognize the above exercise can rapidly become a big job, but I hope it also suggests a useful framework for this discussion.

The first 4 pillars suggested in the OP above are:

1. Print Preparation (which may match the scope of Use Cases 1 & 2 above.)
2. Printing (which probably spans Use Cases 3-12 above)
3. Settings (which would be a subset of Print Preparation and a subset of one or more Maintenance Use Case, so a logical unit to break-out into its own module/menu)
4. Calibration (which would be a Maintainer Use Case)

To my mind, "Settings" is the only pillar that does not correlate directly with a particular Use Case or Workflow.
I would expect to be able to modify any printer performance parameters from the Settings Menu, independently of the reason why I was doing it. If I needed to see the impact of a change in real-time, then I would instead expect to access and modify the "setting" from another menu (e.g. If I want to set "Print Speed" to 100%, and just use the slicer to control that parameter, I would expect to find and adjust Print Speed on the Settings menu. If, on the other hand, I want to change Print Speed "on the fly", while printing, I would expect to find it on the "Tune" submenu of the Printing menu.

There are ao many nuanced layers of detail implicit within the scope of the other 3 "pillars", that I think you will need to elaborate and break them down a little to get to the real "juice".

The goal, I suggest, is to make the logic of the menu system "self-evident" to someone with Maker experience and for it to be easy and intuitive to learn the scope and specific how-to's of the Maintainer role as we go along.

Happy to engage further, if you would like...

[Thinkersbluff]

Thinking about "Pillars" suggests to me that it may also help to establish and document some basic design principles on which to base and validate all design decisions.

e.g.:
You might decide that "The UI design philosophy must be implemented consistently across all screens."
That statement may in turn require that you codify and document the existing design philosophy in some way that helps define and protect that consistency.

Example:
RED text is now used to remind Users that a displayed value may not be correct - as in the case of X-,Y- and Z-axis positions on the MOVE menu. If we anticipate using colour in multiple areas of the UI as a cue to prompt Users to take action, we should also establish a style guide for the UI to ensure the consistency of visual cues.

For instance:
YELLOW is the colour used in the Error Message Screens of this and the stock Creality UI, to alert Users that a fault condition has been detected and automatically acted-upon.

Now we have introduced RED as a visual cue for the User to note that the displayed axis positions may not be correct.

By virtue of using both RED and YELLOW in this UI design, we automatically cue our Users to understand and assume that - in this UI design - RED means WARNING, YELLOW means CAUTION and GREEN means OK. Society has encoded those meanings, and we would have a hard time persuading Users to interpret those three colours any differently.

This is also one of the risks to using colour for coding information - "societal norms" tend to trigger unwarranted questions and assumptions in the minds of the users. Colours like CYAN and WHITE are "safer" colours to use, if we want to define our own meanings or if we just want to make some information easier to find on a crowded screen. RED, YELLOW and GREEN should really be reserved for exclusive use consistent with their traditional societal meanings.

BECAUSE of the above, I recommend that:

• we review the use of YELLOW for displaying M117 messages. If the goal there is only to inform Users, not to signal a problem requiring attention, a more consistent visual cue colour choice may be CYAN or WHITE, which are not as deeply encoded by society.
• we review the use of RED for coding the positional uncertainty and consider instead using YELLOW. I suggest that RED should be reserved for communicating messages even more important than Thermal Runaway, which is currently displayed in YELLOW.
  [UPDATE - I recently had occasion to sit on the MOVE screen and bump the bed forward in 10mm increments. As the bed got closer and closer to the max, I did find the RED more and more apropos. If that coding is variable, maybe it should be YELLOW when the conditions are met to signal "we don't know for sure where it is", and change to RED if one then moves the axis without homing.]

Cheers.

[dryphi]

At the very least, Move should be under Control, or under both Prepare and Control. Some of these actions could fit under more than one category.

[Sebazzz]

Technically that is no issue. If we assign the correct VP we can just pop back to the old screen.

[Thinkersbluff]

I have taken the above analysis a bit further in the attached update. Here, I suggest that the legacy Home menu structure can be seen as following this basic workflow from bottom left to top left: Configure Printer; Level Bed; Prepare to Print; Print.
I then update the analysis at the back of the package to present my logic for a proposed parsing of controls between the Configure and the Prepare menus. We would probably need to agree that Control should become Configure, before we can discuss the proposed lower-level parsing. I am happy to discuss any of this or related ideas.

Issue121_Menu-WorkflowAnalysis.pdf

[Sebazzz]

Pushing this back to CF7 - will look at your workflow analysis when we're in more quiet water.

[Thinkersbluff]

I am refreshing and updating myself on UI/UX design tools and methodologies, while I await the next steps. As much as I enjoy that sort of learning, I am also a bit wary of wasting time - yours and mine - if I am digging deeply into things that do not matter for this exercise when I could be using the time more productively.

Is there an online collaborative UI design environment that you propose we work into, that would support whiteboarding/storyboarding/wireframing? If so, I thought I might invest some useful time learning how to interact with that environment, maybe by capturing some useful sketches and practicing manipulating the elements. Or maybe just a "Zoom call" (or Discord?) with cameras, pencils and sketchbooks + a CR-6 or two?

I am enjoying a quick skim through this workbook, now, on Scribd ($8.95/month for unlimited access to whatever books/mags/etc. they have online.)

You probably have your own favourite approaches to Web Page design, etc..

Happy to familiarize myself with whatever tools/references you recommend.

Cheers

[Sebazzz]

I have taken the above analysis a bit further in the attached update. Here, I suggest that the legacy Home menu structure can be seen as following this basic workflow from bottom left to top left: Configure Printer; Level Bed; Prepare to Print; Print.
I then update the analysis at the back of the package to present my logic for a proposed parsing of controls between the Configure and the Prepare menus. We would probably need to agree that Control should become Configure, before we can discuss the proposed lower-level parsing. I am happy to discuss any of this or related ideas.

Issue121_Menu-WorkflowAnalysis.pdf

I finally got around to reading this, sorry it took a while 😐

Page 3

Yes, this seems pretty right.

but it is also something that users may do as part of their “Prepare to Print” workflow, so it seems reasonable to keep it as its own menu

I expect those users to have G29 in the start gcode, agree? Otherwise it would be users who regularly change their build surface.

Page 4

Preheat settings would move from "prepare" to "configure" I expect.

Page 6

I forgot for a moment that systems are also users 😅

Page 9

Looks close to what I wrote in the start post - note that it is not necessary for a single page only to be reachable from a single location. The firmware remembers "history" of visited pages, so we can for instance put the probe settings in both menus.

[ztakis]

You can follow Creality's four button main screen or make a bold move to two buttons: Print and Setup :)

But IMHO you should decide early on if the UI will be defined heavily by the fact that CR6 has a touchscreen and not a rotary dial.
A touchscreen is obviously faster, less clicks are needed to achieve the same result and you do not want to lose this advantage. IMHO the “easter eggs” that prerelease 6 has, are in the right direction.

[Thinkersbluff]

You can follow Creality's four button main screen or make a bold move to two buttons: Print and Setup :)

I am recommending that we design the UI to support the User workflows. The # of clicks to reach a function will be measured from where the User is, within the menu structure, when they want to activate that function.

In my crude analyses, for instance, I see two main workflows: 1. Configuring the printer and 2. Printing.

The "Configuring" workflow will occur in a variety of scenarios.

• Sometimes, we will just be tuning our machines (e.g. like following the TeachingTech calibration instructions)
• Sometimes, we will be preparing our machine for a particular project (e.g. like moving to PETG or ABS from PLA)
• Sometimes, we may have replaced or repaired a part
• Sometimes, we will be integrating our printer into a larger system (e.g. Connecting to a Host like Octopi, adjusting and testing scripts and communications.)

The "Printing" workflow will vary according to our personal preferences and habits, in which the printer is only one part of a larger "system".

• Sometimes, we will want to inspect and optimize the bed leveling and z offset before every print
• Sometimes, we will want to "set and forget" the bed levelling and offset
• Sometimes, we will want to adjust the offset "live" while we are printing - maybe a test pattern, maybe a skirt, maybe a model.

Of course, the above are only a few of the scenarios one might imagine. It is not practical to try to design for every possible use case, but it would be helpful to identify a few key scenarios to help guide design trade-off decisions and test scripts,

Number of clicks to reach a function is one useful design parameter, but it should be measured within the context of a workflow scenario. Some User needs can be met in more than one way, and not everything should be defined as a UI requirement. Users have options, like adopting a new workflow, using a different component, inserting other steps, etc.. No well-designed product can be all things to all people.

I see logic in the current 4 button approach, if "Control" is changed to "Configure". I think "Control" may have been a poorly chosen translation, if each of the 4 labels is meant to be a verb. Moving the axes is obviously "Controlling" the machine, for instance, but it is not necessarily "Configuring" the machine, the way setting Steps/mm, Jerk & Acceleration would be.

I am sure my analyses have been quite simplistic, though they are also probably overly wordy and "messy".
I am hoping that whatever "obvious" errors or omissions pop into a contributor's mind as they read it will help us to improve and refine that work.

e.g.: What other Workflows should be incorporated?
What other Scenarios should be accomodated?
Should "Prepare" be renamed?

[ztakis]

Here are some suggestions regarding the UI:

[Thinkersbluff]

There are quite a few display screens in the current firmware + I am not aware of any existing documentation of the Use Case Scenarios or Workflows to be supported. It will likely take me a few days to complete the attached WIP effort. I am hoping that the resulting models will prove helpful in more than one way.

Here is Version 0.02, which documents the CF6 PRe4 UI support for these two (2) Workflows:

1. Flash New Firmware
2. Configure Printer.
   Community Firmware UI Analysis - Workflows and Scenarios.pptx

Early feedback is welcome, particularly if anyone thinks this work would be redundant or of particularly low value.

[Thinkersbluff]

In further support of this work, the attached PDF file offers a model of the current (CF6 Pre4) menu structure in a way that I hope makes it both easy & interesting for others to experiment with "affinity diagramming" the current screens.

CAUTION - This work is very likely biased by my personal understanding of the current design. It is my hope that readers who experience "cognitive dissonance" when reviewing these models will be able to follow that "spark" to a better idea.

Firmware Screens Affinity Mapping.pdf

[Sebazzz]

Notes:

1. Agree
   1. Yes, configure would be appropiate.
   2. Yes, this has been a very odd decision to place temperature controls here.

[Thinkersbluff]

Notes:

1. Agree

   1. Yes, configure would be appropiate.
   2. Yes, this has been a very odd decision to place temperature controls here.

Do you find merit and value in the idea of grouping display screens according to a set of high-level abstractions, this way? I have had a lot of past success using this affinity mapping tool and experimenting with abstraction to highlight and expose patterns and anomalies. It is not an end in itself, though, just a throw-away tool, meant to facilitate brain-storming and mutual understanding during design reviews.

I think these specific maps could also be used as a framework, to help clarify, communicate and crystallize the UX design philosophy ithis team chooses to “bake” into the UI. Since they presently need maintaining every time the screens are modified, they only help if they are used to guide and document the actual design discussions and decisions

[Sebazzz]

It definitely helps, but I don't think it is a document that needs to be maintained long term. It can however help get our thoughts in line for reorganizing the menu structure.

[Thinkersbluff]

Some users may appreciate being able to modify Screen Brightness and Screen Timeout settings during long print jobs.
To support that option, it may be a kindness to add screen settings to the "Other Settings" menu under Tune.

[ztakis]

I don’t believe there is any real necessity to implement what you are asking,
HOWEVER
It does show a weakness of the current UI:
You have to start printing to have access to some settings and when you are printing, you cannot access some other settings.
I could say that we need a “Home” button everywhere but..

[Sebazzz]

I like that the workflows of printing itself and the rest is separated. You don't want the user to touch the preheat of leveling options while printing for instance.

[ztakis]

Of course you are right but we might add a “printing default settings” entry in “Control” and make “Tune” land in “Control”
(and that’s a quick suggestion without much thinking).

[Sebazzz]

I think that beside the "Misc" items there isn't much else one might want to during during printing ;)

[Thinkersbluff]

Since print jobs run from hours to days in duration, the thought was to allow access to the screen saver function for users who regret having turned off that auto dimming to be able to work with their screens but now wish they had remembered to turn it back on before starting their print. Based on personal experience.

I still think Control should become Configure and Configure should be specifically what a user uses to set up their machine’s performance parameters. Tune now includes Movement Settings, which implies to me that a user may be adjusting the Configuration mid-print. That implies to me that you mean to support experimentation during printing. That in turn implies to me a wide variety of workflows I have not evaluated for features to which we restrict access when printing.

[ztakis]

I believe that Creality when they name it "Control" they meant "Control panel".
In their recent update they changed the name to "Setup".
I think that "Setup" or "Settings" are more popular and common than "Configure" and basically have the same context.

As for the screensaver, I personally have set it to 5min timeout and forgot about it.

[Sebazzz]

It was such a non-effort, so I added it.

[Sebazzz]

Immediate solution to clear up some space on the crowded control screen - CR6Community/CR-6-touchscreen#46. The rest is for CF7.

[natvincent]

If we anticipate using colour in multiple areas of the UI as a cue to prompt Users to take action, we should also establish a style guide for the UI to ensure the consistency of visual cues.

From my experience with UI design, colour should not be used as the only indicator of a problem. Many people are colour blind, especially red/green colour blind. Using red is particularly problematic because of this. If colour is used, it should be combined with an icon or text .

[Sebazzz]

That is a very good point.

[Thinkersbluff]

If consistency with Marlin LCD menu structures becomes relevant, this resource may be helpful: https://marlinfw.org/docs/features/lcd_menu.html

A similar style of page for the CF6 menu tree might be a helpful resource for CF users and could easily be developed into a linked index into a growing library of supporting documentation, like user manual pages...