3

Our app makes use of a 'Shopping Cart' type metaphor, in which users can select from a variety of items, and then confirm or remove all these items at once. We'll call this explicit save.

The trouble is when we tested on an Android user, this pattern seemed off to him, and the behavior of removing all items when pressing the 'X' was jarring. His assumption was that when selecting an item, it would be saved implicitly, and that the 'X' button would effectively have the same behavior of the 'Done' button.

Is this a commonly expected behavior on Android? (I'm an iOS user). And if so, is it horribly jarring to keep this behavior?

EDIT: The question focuses more on the behavior of the top-left nav button. When a user presses this button, they navigate back to the app's home screen. The question is: when this button is pressed, is the expectation to commit the changes made to the card, or discard them?

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Some notes about this mock:

1) The search bar and auto-complete suggestions appear as an expanded section over top of the cart screen.

2) Since search bar expands and shrinks to show the Cart, the 'X' button is the same UI element the whole time (to try and eliminate confusion about where it will navigate to)

3) Users have the ability to remove items from the cart directly from the list.

4) This is not actually a Shopping app. There is no money exchanged when I press 'Done'. Think of it as putting together a list of things I did today, and 'Done' gives me feedback on the things that I did.

  • Well "x" icon could be perceived as a cancel buton or delete button, but I could bet that more people will see "x" icon a cancel button. The example which comes to mind regarding to you problem is a search text field, user providing some string see a x icon in the filed does the icon is deleting only the text field or reseting all the results system has found? Maybe you should user a big button "delete all" beneath the list of items not in the header, leave header with options back and done only? – steppenwolf Feb 19 '16 at 12:37
1

I am not too sure if it is an Android issue. We had a similar issue back then - not with the cart, but with applying several filters in a catalog. The "X" you use generally was perceived as "Close" or "Cancel", not delete, while "Done" implies that the action done is not discarded, but rather accepted. So "Done" would be similar to "Okay" or even "Save". Then, in your mockup, I think it might be confusing to use the "X" on the top left, while it usually is used for "close the modal" on the top right, which might confuse.

Then again, iOS natively offers item options behind the item slide - swipe it to the left/right and get additional options, or you could also use a long press. This will give single-item options. If you wish to multi-select (which I would question that you actually want your customers to do that: Delete "All"), iOS usually offers the EDIT mode, which then allows to either multi-check some items or delete them all. THIS behavior, then, is also provided by Android's contextual action bars (you might google that up, if this not a familiar concept to you. Basically it says: depending on the context, actions are added to the action bar. So if you are in edit mode, functionality like "delete" or "cut" or "copy" gets added as an icon to the bar).

So my conclusion would be: Instead of focusing on DELETE ALL, focus of getting to an "edit" mode instead. Reasons for that:

  • "X" is most likely not understood as "DELETE" (our own surveys showed that a clear "delete" action is only expected with a trash can icon)
  • You do not want users to delete all items at once
  • You might want to add a "select some and only delete these few items". Why? Users tend to use the cart as a wishlist, then only buy a few. Not using the "delete some" functionality enforces users to repeatedly delete one item after the other. Then again, adding an "Add to wishlist" feature to the cart helps users saving the items for a later purchase instead of deleting them. I would make this one more prominent than the "delete item" feature.
  • Android's and iOS' edit item list mode should solve the issue of insufficient space and create a similar feeling. Second would be, that you would get rid of some options in the initial screen.

enter image description here

  • Hey, thanks for the response! I think I may have misdirected in my question. My question is less about having a Delete All function (though that may be a discussion point for later). It's more about the expected behavior when leaving the page, that is: Save or Discard. I have been lead to believe that the expectation is different between platforms;iOS generally uses Explicit save, whereas Android saves implicitly with every action – Adam Thompson Nov 20 '15 at 18:28
  • The Save expectation on iOS is that the device auto-saves every 2 seconds. The user never saves anything. That is how it has worked for 9 years. – Simon White Feb 19 '16 at 12:35
0

You should consider putting the discard button at the bottom of the list of items:

* Item One
* Item Two
* Item Three

[Clear Shopping Cart]

… because your X is ambiguous and it is placed where the user expects the back button to be.

Also, the button on the top right in iOS should not be labeled “Done” if it commits the purchase. On iOS, “Done” doesn’t mean “OK” or “commit” — it means more like “I’m done with this view, dismiss it.” You should have an explicit “Purchase” button. Maybe like this:

* Item One
* Item Two
* Item Three

[Purchase These Items]  
[Clear Shopping Cart]
0

Android has a Contextual Action Bar (CAB) for list item selection, allowing multi-selection, deletion, and perhaps custom actions to be performed in a manner that helps make it clear what is going on (e.g. highlighting selected items). That pattern has been around for a long time and is constantly used throughout Google apps such as Messages and Contacts.

Hijacking the Done/Discard pattern to turn discard into a custom action of your choosing is clearly not an appropriate approach on Android.

On Android, the 'x' is used for modal-type windows, such as CAB. I have also used it for AppWidget configuration activities, which I think are best described as modal-type in the way the interact with the User and the system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.