Component - Action Bar Use cases and UX Elements

[joseegm]

641 goal: Define a for every user case a behaviour for the UX elements from #759

Task

• [x] Identify Uses cases
• [x] Define UX elements behaviour
• [x] Define Flow/Steps use
• [x] Define Mobile use
• [ ] Visual Design
• [ ] Document results on the wiki
• [x] Update file on Box

[joseegm]

Uses cases and UX Elements behaviour

1. Only display the Page Title. The page title will be present at all times.

2. Display the Back button and the Page title

3. The page can have Actions that operates on the object the page is representing. There is a max of 4 actions to be shown. If the page have more use next case Also can be combined with the back button

4. The page have 5 or more actions. In this case the actions will be put under a "..." action that will display a Actions Menu with the list of the actions. Also can be combined with the back button

5. Form. When the page presents a form. As soon as the user modifies any form field the options on the page will be switched by only Cancel and Save Buttons. After trigering one of the actions Save or Cancel the Action bar return to the original state.

6. Flow / Steps When the user is required to navigate multiple screen in a defined order. The Location element can display: how many steps the flow have; the current step with Page Title for that step.

   First step The Previous action is disabled. The Save action is disabled when the flow goal is to create a new object. But when editing an object the Save action stays enabled at any step.

   Intermediate step Previous and Next actions are enabled. Save behavior is the same as on First Step

   Final step

   Next action is disabled. Save action is active.

   Prototype Video for the flow behaviour: techne-action-bar.mp4.zip

   The Steps indicators on the Location element link to the corresponding screen.

   When validation is needed a particular step, before advancing to the next step: the Next action and the subsequent Steps indicators are disabled.

   When the screen is validated and the user can continue to the next step: the Next action and corresponding Step indicator are enabled.

[joseegm]

Mobile use case and behaviour

The Tablet inflection stays the same as desktop.

For Mobile phones:

The Action Bar will be divided in two:

• Top part: containing Back Button and Location Element
• Bottom part: containing the Action Element

Mobile use cases

The same Uses cases from desktop (on https://github.com/SAP/techne/issues/793#issuecomment-314776899) are valid. Relevant cases:

Use Case	Wireframe
1
2
3
4
5
6

[denisewildner]

I like the updated UX concept! Nevertheless I would recommend user testing the interaction from point 3. and 5.: How does the user perceive (if at all) the switch from multiple actions to Cancel / Save, when he edits the form.

I also miss a clear description on the behaviour when to display the "Back"-button ;) But I agree that it should only appear when there's no way to navigate back via the left side navigation, and always displaying it on mobile.

[joseegm]

@denisewildner Thanks for the review.

I'll create a separate issue for the test, it doesn't affect the UX elements so it can be done in parallel; to test if the interaction works.

Agreed, the explanation of when to use the Back Button can be more clear. I'll expand that as well.

[jeannewalters]

@joseegm - the only thing I would add to consider and add in is what to do when titles for steps next to the step # and page titles are longer than the allotted space allowed. Unless there is a UX involved with the team, they not consider this during implementation.

[joseegm]

This will be document. And the solution will be to put an elipsis via CSS on the implementation, as follows:

[jeannewalters]

@joseegm @LeoT7508 There is no priority in the wires placed on Save or Next - every button has the same priority. Is this something that is addressed in another ticket already? Heuristically, this is something that should be addressed in wires and shown in visuals.

[joseegm]

@jeannewalters Yes, the priority on the Actions will be addressed on a separate ticket since it is common for all actions.

[joseegm]

@jeannewalters The priority of the actions is defined at #826

[joseegm]

Back button use case

The Back Button is only used, in the case where the user navigates from a Collection on screen to the Object Details page; in this case there is no option on any other Navigation Component to go Back to the Collection. That's why the Back Button is needed. Exemplified on the next wireframe

[joseegm]

Full documentation now at https://github.com/SAP/techne/wiki/Action-Bar-Design

[LeoT7508]

@joseegm

I'm curious as to why we need a "Previous" & "Next" button when the user can use the 1,2,3 to click forward or backward.

Something to think about.

[LeoT7508]

@joseegm

Attached are the flushed out Action Bar design specs.

I changed very little. I kept the Flow & Steps labels below the icons to keep it consistent with the rest of the buttons in the action bar. Also I added a green status for already completed steps along with a check mark for visual confirmation that the step was completed.

I also put together a small States document for the Action Bar, which will work somewhat different than regular buttons in some cases.

If my suggestions are not valid please advise.

Thanks.

[joseegm]

Closing #824 since visual design is happening over here

[joseegm]

Thanks @LeoT7508 Looks good.

To your question from https://github.com/SAP/techne/issues/793#issuecomment-316123583

The Next and Previous buttons give a sequential navigation - one only button takes you to the next step. The Steps Indicators are for navigating -jump- to a particular step quickly. So there fullfill different functions.

Things that need more work

1. The actions don't have the action color -blue-, for that we may need to change the background of the toolbar to something else. There was this example The back button should as well have the action color

2. Without the vertical lines it looks more clean, so we can remove them

3. The solution for the Steps doesn't scale well. They are suposed to indicate the step the user is in. See bellow for a concrete example So the can will be longer than "Step 1"

4. The Step Completed indicator obscure the Step number. Also not all flows needs to "complete" a step. So don't need the completed option.

   The right behaviour to do validation before advancing to the next step is explained on https://github.com/SAP/techne/wiki/Action-Bar-Design#uses-cases-and-ux-elements-behaviour - Point 6

   The Next Step indicator and the Next Action are disabled till the current step validates. Wireframes added for context

   Screen is not yet valid and the user cannot advance to the next step.

   Screen is validated and the user can advance to the next step.

5. The Selected/Current Step Indicator Color is the same as the action color. We should use only the Action color for Actions, not for status.

6. Reduce the use of shadows. Let's keep the use of shadows to a minimum. Unless they reinforce the interactivity, like the shadow on the hover card: that signal the hovered card is a little more "elevated" than the rest.

   The particular case here is the Completed Step.

7. Keep in mind the Actions will have the same status as the other actions. So you may want to keep the style similar for consistency reasons.

8. For the Actions Priority (defined here https://github.com/SAP/techne/wiki/Actions#actions-priority), posted here for context

   Take in count the Action Color is the same as the top bar. It will look as if the main action is part of the Top Bar.

[joseegm]

After discussing all options with @denisewildner. We arrived to the following solution for mobile.

Problem

Steps visualisation don't scale when the quantity of steps is more that 4.

Solution

Display Only the Step Indicators.

This way the more important information: the total number of steps and the step the user is currently will be shown.

We'll recommend keep using the same pattern that is currently in use to also put the "Page Title" as part of the content of the page.

Not used solutions

• Dropdown: Doesn't display the total of steps without interaction. Doesn't reflect the consequent nature of a steps flow. The uses is not changing the whole context of the page.
• Horizontal Scrollable Location element: it is hard to use when the same element can be scrolled and also tapped in a reduced space like the Location Element in the Action bar.

[xak]

Separating the actions (at the bottom) from the title (at the top) in the Mobile Use Cases will be difficult in CSS. Also, if the header, action bar and the actions are all fixed on the screen it will create a small window to view the actual content. https://github.com/SAP/techne/issues/793#issuecomment-315319278

If the action bar lock-up can remain the same (as it is now) it will be easier to implement and less fragile.

[LeoT7508]

@joseegm

Should we proceed? Or have more discussion about @xak concerns? Which seem to valid.

[joseegm]

@xak Separating the Actions Elements from the Back Button and the Location element was decided for the following:

On Mobile.

1. Gain more real state for all the UX Elements
2. Position of the actions at the bottom, to facilitate the use via thumb -most common interation on mobile.

3. The window problem is not a problem there is plenty of space inside the bars.

   In the extreme case... That can be solved if only the Actions Elements are visible at all times and the Back button and Location Element can be scrolled along with the page.

   

All those solutions can be implemented using CSS

Questions:

1. What you mean by fragile?
2. There is any concrete CSS problem to implement this?

[joseegm]

@LeoT7508 Zack's questions were answered above.

We can proceed with this, thanks.

[xak]

@joseegm Since the buttons bar only appears after an edit is made, it's possible that the buttons could cover the input field being edited.

[joseegm]

@xak All uses cases where the Action Elements appear are documented already. There is not Edit mode.

It is possible that it happen like that, but they are ways to put the buttons behind the keyboard. So you can only access them when the keyboard is closed.

Anyway, that's a thing we have to try with actual HTML/CSS not with wireframes. If doesn't work then we can change it.

The keyboard is only needed when editing a form input and you can navigate the form inputs using the arrows to jump between form inputs. Noted on the screenshot. So the user doesn't have to scroll in the small window. That problem was solved by the designer of mobile touch keyboards long ago

[xak]

I'm not talking about tabbing between fields, I'm talking about actively editing a field on a mobile device. By "Edit Mode" I mean the state of a view when edits have occurred. A view will load and show no actions, yet, as seen in the current Builder, the actions appear when a change is made to any form value. Wiki case #5 (Form) indicates that this is the expected behavior, right?

Here is the scenario ...

1. User navigates to a view with editable fields. No action buttons or keyboard are visible.

2. User clicks into a field. Keyboard slides up but no action buttons are visible.

3. User begins typing (editing) the field. Keyboard is visible and the action buttons appear since the input value has changed.

You can see that the buttons obscure the field being edited behind it.

Additional programming would be necessary to "put the buttons behind the keyboard ... only access them when the keyboard is closed." I can do some research but to my knowledge this is not possible with HTML and CSS alone.

Given the extremely low usage of mobile devices, this solution introduces more complexity for very little value.

[joseegm]

@xak The right architecture and implementation will allow the mobile browser to decide when to show or hide the Action Elements automatically. Without any custom Javascript or overhead on the implementation. This is a common problem already solved by the mobile browser.

Have test it on a prototype and it works just fine. See the attached screen-cast mobile-actions.mov.zip

It is a viable solution for getting more space for the actions and the location elements. Also it is easy to implement in CSS.

No need to change this solution. It is viable and is working on the prototype.

I think we can now continue and finish this one.

[LeoT7508]

@joseegm

Im not sure this test you posted proves much, it shows that the controls act erratically. Sometimes the actions buttons are there, sometimes they are half there, sometimes you have to close the keyboard before you can see the buttons. Also the content you are using isn't put in the right context. You are using tiny fields and small text with very tight leading. I think you should test this on a phone and see how it works out. I can provide screenshots of actual content or a full designed layout. But based off what we have so far I don't think its enough to pass this through to the next step.

[jeannewalters]

It sounds like this needs user testing as soon as it's built (and before it's released) to be 100% sure this is the right approach for users. @joseegm I would agree with @LeoT7508 that the prototype doesn't prove this will work for the reasons he said above. Tests should be done with the smallest viewport we are supporting as well. I know that Techne 2.0 is not being designed with a mobile first approach but we need to give teams that do use that approach the best experience for their users in a mobile space.

[xak]

@joseegm @LeoT7508 I see no value in rearchitecting this at this time. For the MVP we should use the patterns we have now unless we have clear feedback that the current experience is a problem.

Putting the actions on the bottom may be preferred by UX but it is a big change that affects user expectations (different from current setup) and extends the development time. An extremely small number of people are using the mobile UIs. The additional effort and potential for new bugs outweigh the value gained. Can we defer this for now in favor of not introducing new complexity.

One more thing ... can I see a real example of this?

I cannot find a Wizard flow in Builder but I'm curious how the page title is placed below the nav in this one case. It is not ideal to move the title from the Action Bar to the content area — primarily, it changes the bar height which complicates fixed placement and adds a dependency for the content area to include additional top padding to accommodate the title. Alternately, the title could be duplicated in the content but it would need to be hidden at larger screens. Those presentational requirements will be hard to communicate and/or enforce.

Thanks.

[LeoT7508]

@joseegm @xak @jeannewalters

Since development & UX still have concerns we should continue to iterate on this.

I will create a visual for what Zack asked for. I think it is important to see how this will look with real content. That was one of my main points from my previous comment.

[LeoT7508]

@joseegm @xak @jeannewalters

I created some screens with real info, its all to scale with proper padding and actions included.

If you want an accurate test open these up on your phone to get proper scale.

[joseegm]

I want to notice we have been discussing this for 20+ days now, it is time to finish this one.

@jeannewalters in response to https://github.com/SAP/techne/issues/793#issuecomment-319748387

We talked about it in by the end of the meeting yesterday. Tested also in iPhone 5 size as well. Screencast here:

action-bar-iphone-5.mov.zip

The solution works as well in small sizes. Again: The browser removes all elements obscuring the inputs by default. No extra code needed there.

@xak We have not space to put the actions at the top in the first place. There is no development overhead as minimal stand CSS statements are needed, that was proved on the prototype.

See example bellow.

Again: the recommendation is not to display the title as part of the bar on mobile but to have the title as part of the content of the page those are separate issues.

@LeoT7508 The mobile browser hides all other elements, so the third case you mocked up won't happen. The url bar will decrease in size when the user is scrolling and the Actions elements will be hidden if they are too close to the inputs. Please see the above screencast of real browser behaviour. The sizes of the inputs and actions are not relevant for this behaviour since the browser take care of all calculations.

Now all questions are properly addressed, answered and tested in the prototype. So we can finally finish this.

[LeoT7508]

@joseegm @xak @saadmhybris

It doesn't sound like development is satisfied here, but I will post visuals to not block anything from a design side.

[joseegm]

@LeoT7508 Thanks for speeding up the things. Really appreciated.

Quick question: The dimensions and spacing for the actions stay the same as #787, right?

@saadmhybris We can continue with this solution and test it more when it is implemented. As said HTML/CSS the prototypes present no problems with the implementation.

I'll send you the details of the HTML/CSS prototype.

[LeoT7508]

@joseegm

Yes, all the dimensions are the same. These mobile screens are just saved out @2x that why they seem large.

[gcho1023]

can we get the status of this ticket and see if we need to create a new ticket with the right requirements based on the latest use cases? @joseegm