Description:
Last week we discussed a screen where users could decide what characteristics they wished to prioritize in their network set-up. The main interaction for this was a stack of three blocks, each one with a different characteristics. Users could change their order from highest to lowest priority by using arrow buttons on each block. Click the up arrow to move a block up one slot, click down to move a block down a slot, and so on.
What does this feature afford users?
It allows users to quickly customize the network they're building using the wizard. Asking users to prioritize three key characteristics would force them to think about their task and make some key decisions. At the same time, limiting the priority decisions to a small number of items makes sure the decision task isn't too onerous. It makes sure that the wizard can guide the user through only the stuff necessary for their task rather than through all possible blocks.
What are its constraints and how do they help or hinder users?
There's no way to set items at equal priority. This could be helpful since, based on discussions with Erica, it seems like there isn't a way to equalize priorities like that, so insisting on 1-2-3 priority forces users to understand the trade-offs of how networks are built. However, this could get annoying to people to really want to balance two characteristics at equal priority, especially if there's no explanation for why they can't do that. At the same time the insistence on priorities helps streamline the later parts of the wizard, so it would pay off for users down the line.
The use of button-clicking to prioritize characteristics could potentially get very annoying, especially if the user can't make up their mind, because that would be a lot of clicking. Admittedly, it's only a three-item list, so the maximum number of clicks ever needed to move an item would be two (since we would not allow items to wrap around), but it could still quickly get annoying. Maybe the clicks would force people to think carefully about how they're moving things around, but I think annoyance is more likely.
No additional priorities. Based on our talk last week, we have three characteristics in a list and a couple others are are set using a different format. There's no way for users to pick which three characteristics go into the prioritizing list, even if one of the non-list characteristics is what they might be interested in. Again, this streamlines the later part of the wizard, even if the lack of customization might annoy users, even novice ones.
How does the feature signify its affordance or how to use it to users?
The arrow buttons would signify what directions a block could move in. Based on the concept we were looking at last week, it seems like for the top item the 'up' arrow would be grayed out and for the bottom area the 'down' arrow would be grayed out, so it would be obvious which arrows were clickable and which were not. On the other hand, I don't remember seeing anything about how users would know the arrows were clickable, and I don't remember anything explicitly indicating order of priority (i.e. is the top the highest priority?).
What conventions does this feature either respond to, incorporate, or reject, either in the context of interface design generally or GNURadio specifically?
Overall the wizard idea rejects the onboarding philosophy of the GNURadio design, which is that there isn't/shouldn't/doesn't need to be one. The whole concept of the wizard is to ease people into how to use GNURadio and teach them how to do it.
As for the priority list specifically, it doesn't allow for drag-and-drop, which I think would be a more natural way for people to interact with a group of interface items that they need to order. Compared to that, the constant clicking up and down feels clunkier and only workable due to the small number of items we're asking people to prioritize. Drag-and-drop would also match the existing ability to drag-and-drop blocks onto the work area.
There's a NN/g article that summarizes the difference between customization and personalization like this: "Customization gives control to the user and personalization gives control to the site." We aren't working with a web site but I think that sentiment is still true; by implementing this kind of priority-selection feature, we're giving users a limited ability to personalize the wizard to their particular task and needs, which I think fits with some ongoing trends in UX in general.
How will you go about arguing for the inclusion of this feature?
First I'd want to review the feature and why we chose it, and also to ask any detractors what their specific concerns were so I could address those directly. But, if had to make a general defense, I would probably point out how useful it is, how it fits into our overall task of building a wizard and teaching users how to use GNURadio, and how the client (Erica) was happy with and advocated for such a feature.
Description: Last week we discussed a screen where users could decide what characteristics they wished to prioritize in their network set-up. The main interaction for this was a stack of three blocks, each one with a different characteristics. Users could change their order from highest to lowest priority by using arrow buttons on each block. Click the up arrow to move a block up one slot, click down to move a block down a slot, and so on.
What does this feature afford users? It allows users to quickly customize the network they're building using the wizard. Asking users to prioritize three key characteristics would force them to think about their task and make some key decisions. At the same time, limiting the priority decisions to a small number of items makes sure the decision task isn't too onerous. It makes sure that the wizard can guide the user through only the stuff necessary for their task rather than through all possible blocks.
What are its constraints and how do they help or hinder users?
How does the feature signify its affordance or how to use it to users? The arrow buttons would signify what directions a block could move in. Based on the concept we were looking at last week, it seems like for the top item the 'up' arrow would be grayed out and for the bottom area the 'down' arrow would be grayed out, so it would be obvious which arrows were clickable and which were not. On the other hand, I don't remember seeing anything about how users would know the arrows were clickable, and I don't remember anything explicitly indicating order of priority (i.e. is the top the highest priority?).
What conventions does this feature either respond to, incorporate, or reject, either in the context of interface design generally or GNURadio specifically? Overall the wizard idea rejects the onboarding philosophy of the GNURadio design, which is that there isn't/shouldn't/doesn't need to be one. The whole concept of the wizard is to ease people into how to use GNURadio and teach them how to do it.
As for the priority list specifically, it doesn't allow for drag-and-drop, which I think would be a more natural way for people to interact with a group of interface items that they need to order. Compared to that, the constant clicking up and down feels clunkier and only workable due to the small number of items we're asking people to prioritize. Drag-and-drop would also match the existing ability to drag-and-drop blocks onto the work area.
There's a NN/g article that summarizes the difference between customization and personalization like this: "Customization gives control to the user and personalization gives control to the site." We aren't working with a web site but I think that sentiment is still true; by implementing this kind of priority-selection feature, we're giving users a limited ability to personalize the wizard to their particular task and needs, which I think fits with some ongoing trends in UX in general.
How will you go about arguing for the inclusion of this feature? First I'd want to review the feature and why we chose it, and also to ask any detractors what their specific concerns were so I could address those directly. But, if had to make a general defense, I would probably point out how useful it is, how it fits into our overall task of building a wizard and teaching users how to use GNURadio, and how the client (Erica) was happy with and advocated for such a feature.