Design consistent UI interface for keyboard+mouse and touch devices #188
Comments
|
There are clearly a few strands to this issue:
I don't think we have a clear picture of any of these questions currently, so this design effort is likely to be a long-running evolutionary effort. |
|
This has come up again while designing the session list. I’ll elaborate later. |
|
It seems clear that Apple don’t want developers using long press for apps in mobile Safari:
The latter link, in particular, is on Apple's own bug tracker, was filed in July 2020, and is still marked "NEW" with nobody assigned to it. Apple’s own web apps don’t even support long press. If you use iCloud Drive on icloud.com, the only way to perform operations like delete & rename on files is to press the selection mode button, select one or more files, and then press the corresponding action icon (trash can, etc.). This is awful! However, I think it would be unwise to try to work around it. That usually doesn’t end well with Apple products, in my experience. Therefore, I think we need to ignore long press as an interaction mechanism in Hackworth Codes. This probably means we’ll need more buttons and other explicit/visible UI elements. The downside is that our UI will be a bit more cluttered than I would prefer, but the good news is that features will be more discoverable. |
dhess
added a commit
that referenced
this issue
Dec 5, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 5, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 5, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 6, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 6, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 6, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 7, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 7, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
dhess
added a commit
that referenced
this issue
Dec 7, 2022
These are styled now as cards, with buttons for favoriting & sharing (not yet hooked up, as the backend lacks support for this). I have some concerns about how busy the UI is now, but I think this is better than the alternatives I could come up with, which are: 1. Hide favoriting and sharing behind a long press, which it appears Apple do not want to support on mobile Safari: #188 (comment) 2. Single-icon favorite and share buttons, but these are not particularly informative since they don't have any explanatory text. I'm open to option 2, as they would take up less screen space and there would be fewer words on the page, but it's not as discoverable as the solution implemented here, which includes the words "Favorite" and "Share" along with the iconic representations. We could support both, and only display the icons in a more advanced mode, once the student has some experience using the application. Note that this commit introduces a new style of button, a sort of built-in style for cards. I played around with our standard `UIButton` instead of this new style, as I'm reluctant to add new UI design language in general; but I think in this case, because we're adding a major new UI element in the cards themselves, that it makes sense that they have their own button style. The `UIButton` looked awful in this context, IMO.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should come up with some system of input controls (click, right-click, keypresses, hover, dragging etc) for our webapp to use, bearing in mind that it should work smoothly for both traditional desktops and also mobile devices. It may be that we want different controls on different devices (e.g. right-click on an actual mouse is an easy gesture, but does not exist as such on touchscreens), though it would be nice if the correspondence was obvious.
There are also potential accessibility concerns here. For example, small targets, swift double-click-ing...
Currently we have the "interactive tree" story in our storybook #167 (which is intended for visualisation during development and has not worried about touch devices). It uses
onclickto grow a tree andoncontextmenu("right-click") to prune. This is nice with a traditional mouse; it works on android (long-press triggers pruning); but does not work on iPad (I cannot trigger pruning; I don't know how easy it would be to "fix" - I have not investigated much). Whilst ok for development visualisation, it is clearly not acceptable in a released product!The input actions I think we will certainly want are (in terms of traditional desktop input):
I don't know whether we will want anything like the following:
Of course, there may be other things I have not thought of here!
The text was updated successfully, but these errors were encountered: