[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-calendar-app Milestone: 0.5 => 0.6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: Triaged Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Fix Released Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the UI - Toolkit spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
The link in my previous comment should be: https://developer.ubuntu.com/en/blog/2016/02/24/pageheader-tutorial/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: Triaged Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Fix Released Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the UI
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
This was cleared up by design. Cancel/confirm headers now look very different from headers with a back button. See, for example, the "Extending the header" example on https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1408015 Closing the bug for UITK. ** Changed in: ubuntu-ui-toolkit (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: Triaged Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Fix Released Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-calendar-app Assignee: (unassigned) => Nekhelesh Ramananthan (nik90) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: Triaged Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: In Progress Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the UI - Toolkit spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-calendar-app Milestone: None => 0.5 ** Changed in: ubuntu-calendar-app Status: New => Triaged ** Changed in: ubuntu-calendar-app Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: Triaged Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: In Progress Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-ux Status: In Progress => Fix Committed ** Changed in: ubuntu-ui-toolkit (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: In Progress Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1#
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
New designs are coming which makes this more clear. ** Changed in: ubuntu-ux Status: Fix Committed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: In Progress Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-clock-app Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Fix Released Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment & resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Clock app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the "feedback bubble" to the UI. If the user taps back before saving the feedback bubble states, e.g. "Alarm not saved". If the tick icon is tapped, it can state "Alarm saved" (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or "save added". The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a "Send Order" or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means < CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the UI - Toolkit spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-clock-app Milestone: 3.x.backlog = 3.5 ** Changed in: ubuntu-clock-app Assignee: (unassigned) = Nekhelesh Ramananthan (nik90) ** Changed in: ubuntu-clock-app Status: Incomplete = In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: In Progress Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Calendar app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
Fix committed into lp:ubuntu-clock-app at revision 329, scheduled for release in ubuntu-clock-app, milestone 3.5 ** Changed in: ubuntu-clock-app Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Fix Committed Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Calendar app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Description changed: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- - The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. + The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. - Calendar app: - When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. + Clock app: + When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: - There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. + There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Branch linked: lp:~nik90/ubuntu-clock-app/improve-header- confirmation-behavior -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: In Progress Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Calendar app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I will add the footer/toolbar idea to potential new projects for design. Please see for reference the notification spec: https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# Please see for reference the UI - Toolkit spec:
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
@Nekhelesh The issue is that the new framework for notifications is not implemented yet. This means that there is no working feedback bubble. I am not sure if the notification system will be part of unity or run as a standalone. The safest way for now is to consider the approach to show confirmation actions, e.g. in the header, by enabling or disabling them. Hope this helps. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Calendar app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the UI-Toolit and I
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
Updated bug description with design solutions hence marking the bug as Fix Committed. ** Description changed: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) + + --- UX comment resolution -- + + The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. + If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. + + In all here described cases the UX can be improved easily by adding + clarity to the UI and sometimes just adding a call to action. + + The header can be fixed or can go off-screen the specification for that + lies with the designer/developer. This means if I have an important + action in the header which I want to present to the user all the time, + then the header stays fixed, even if the content is scrolled. + + Calendar app: + When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. + This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. + If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). + In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. + + Note app: + There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. + + While it is ok to use a Send Order or a NEXT at the end of a form, for + some instances and apps it won't be efficient. This means CANCEL/BACK + and CONFIRM (tick/save/done) can sit in the header but it is not + possible to control apps which don't want to user out UI-Toolkit, hence + the other solutions will exist too. + + We are constantly improving the UI-Toolit and I will add the + footer/toolbar idea to potential new projects for design. + + Please see for reference the notification spec: + https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit?pli=1# + + Please see for reference the UI - Toolkit spec: + https://docs.google.com/document/d/1nFm8xiYhKXXuEO_IvMXoD0lASbYzYXva1BWMVanU3iw/edit#heading=h.a8gwztgmbhpq ** Changed in: ubuntu-ux Status: Triaged = Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
@Olga, thnx for the design resolution. I can make the above changes to the clock app to resolve the issue. The one thing I am not clear about is the feedback bubble that you mentioned. I looked at the Notification Spec document and the feedback bubble shown there are ones shown by Unity8 and not something I have seen apps themselves being able to show. Could you elaborate a bit more on that? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Fix Committed Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) --- UX comment resolution -- The back button in the header should never be used as a confirmation but can mean CANCEL and not just BACK. If an action or any alterations within the content/screen have to be confirmed/saved then it requires a visible call to action. This call to action sits by default in the header unless differently specified by designer/developer. In all here described cases the UX can be improved easily by adding clarity to the UI and sometimes just adding a call to action. The header can be fixed or can go off-screen the specification for that lies with the designer/developer. This means if I have an important action in the header which I want to present to the user all the time, then the header stays fixed, even if the content is scrolled. Calendar app: When creating a new alarm by swiping from the bottom of the screen, the tick (confirmation) icon should be disabled. Only after interacting with the screen, by changing one of the parameters for example, the tick should be enabled. This will signal to user that there was a change and this needs to be confirmed. Even more informative is a simple word instead of the tick: SAVE. The SAVE option is a new addition to the header and wasn't available so far. This concept is already documented in the UI - Toolkit spec which is at the bottom of this post. If user taps back before saving then the alarm won't be created. Additionally there can be visual feedback by adding the feedback bubble to the UI. If the user taps back before saving the feedback bubble states, e.g. Alarm not saved. If the tick icon is tapped, it can state Alarm saved (see Notification spec). In the Repeat section the select all icon has to move one to the left and a tick or save added. The behaviour will then follow as described above. Note app: There is nothing wrong with the note app approach but it is a custom made behaviour which is up to the developer. This person decided not to use our pattern and include a tick or SAVE into the header. There are many note taking apps on iOS which are not using their patterns either. This doesn't mean they are bad, they just work differently. While it is ok to use a Send Order or a NEXT at the end of a form, for some instances and apps it won't be efficient. This means CANCEL/BACK and CONFIRM (tick/save/done) can sit in the header but it is not possible to control apps which don't want to user out UI- Toolkit, hence the other solutions will exist too. We are constantly improving the
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-clock-app Milestone: None = 3.x.backlog -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Triaged Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/quick-memo/+bug/1408015/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Changed in: ubuntu-ux Assignee: Magdalena Mirowicz (magdalena-mirowicz) = Olga Kemmet (olga-kemmet) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Triaged Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/quick-memo/+bug/1408015/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
This morning I came across the headline, 4 iOS Rules to Break, and I thought, I bet one of those is putting Cancel/Confirm actions in the header. Sure enough: On iOS, the Done button is often displayed in a navigation bar at the top of the page. Sometimes the form Submit button (whether called Submit or something else — for instance, Place Order) is also placed at the top of the form. This pattern has started to trickle into Android apps as well. Even in iOS apps we recommend against following this pattern for the simple reason that it goes against the natural top–bottom workflow on the page. As users fill in the form, they usually do it top to bottom. When they get to the end of it, they expect to find a Submit button right there, next to the last field they have completed. Most of the time, when people don’t find it there, they get confused and start looking around, not knowing what to do. http://www.nngroup.com/articles/4-ios-rules-break/ In Ubuntu it's even worse than in iOS, because (a) we use ⟨ to mean two different things and (b) the ✓ doesn't even have text like it does in iOS. I think the rule should be simple: Never put cancel or confirm actions in the header. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Triaged Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/quick-memo/+bug/1408015/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1408015] Re: [sdk][UX] Confirmation in the header bar confusing
** Summary changed: - [sdk] Confirmation in the header bar confusing + [sdk][UX] Confirmation in the header bar confusing ** Changed in: ubuntu-clock-app Status: New = Incomplete ** Changed in: ubuntu-clock-app Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1408015 Title: [sdk][UX] Confirmation in the header bar confusing Status in Quick Memo: New Status in Ubuntu Calendar App: New Status in Ubuntu Clock App: Incomplete Status in Ubuntu UX: Triaged Status in ubuntu-ui-toolkit package in Ubuntu: Confirmed Bug description: Imagine a form of some sort, you fill a few fields of data top-down, and at the end of it you need to tap in the header at the top to save/confirm. Pair that with the header going off-screen to leave more screen for the content, you have to pull the header in first (and you need to know that's where the button will be). An example of this behaviour is the calendar app when adding/editing an event. One other example (although that could be improved easily by auto-saving the new note as soon as it's edited) is the Quick Memo app, where when you create a note in the first place you need to tap the ✓ icon, but when you're editing, it's all auto-saved and you need to tap 〈 to go back to the list of notes. I feel like we need to at least come up with clear guidance on what belongs in the header, and where a footer with buttons should be used (we have a way to stick something on top of the keyboard after all¹). http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.MainView /#anchorToKeyboard-prop ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: qtdeclarative5-ubuntu-ui-toolkit-plugin 1.1.1364+15.04.20141209-0ubuntu2 Uname: Linux 3.4.67 armv7l ApportVersion: 2.15-0ubuntu3 Architecture: armhf Date: Tue Jan 6 17:03:54 2015 InstallationDate: Installed on 2014-12-17 (20 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20141217-020204) SourcePackage: ubuntu-ui-toolkit UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/quick-memo/+bug/1408015/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
