6

I am writing an android application that manages a list of Todo tasks. So each task have properties such as title, due date, priority, importance and so on.

So there will be a list of all the tasks, and then when the user selects a task, he should be able to view/edit the task, here's where I am confused about which "pattern" to use.

Looking at the stock android apps on my Nexus S with Jelly Bean, there are a couple of patterns:

  1. Calendar App Upon clicking on a calendar entry, a view mode is displayed, with the edit and delete button in the action bar, clicking on edit will make all the fields editable.

    enter image description here

  2. Contacts App Quite similar to the above, besides that, I need to click Menu->Edit, as there are no edit icon in the action bar

    enter image description here

  3. Alarm Clock App This is totally different, and represent what I thought to be a better interface, basically every field is displayed as an item in the List, and then clicking each of them will create a popup, with an OK and Cancel button.

    enter image description here

  4. Last is the Tasks application, which does away with the View mode, and just changes into Edit mode straight away:

    enter image description here

What are the guidelines of which type of UI to choose?

2
  • 2
    whichever that you like. follow your heart.
    – Magnolia
    Commented Oct 23, 2012 at 7:43
  • edit application form some mistakes have
    – Maniteja
    Commented Apr 3, 2021 at 5:52

3 Answers 3

4

When thinking about UI patterns with this much subtlety it helps to think about what frequency of use a particular feature will get. For example. In the Calendar app the majority of use I imagine will be adding new events and viewing (or accessing) existing events. When the user's primary motive is to find information from existing events, a non-editable view makes sense because it adds the least distraction for the majority of their tasks. Copying text on an editable view for example would force the virtual keyboard to open and add an extra layer of interaction. Therefore the decision to use an edit button to edit the event in this case makes sense.

When struggling with these types of decisions I would think about the context your users are in and what frequency they perform each task.

Google's design docs may also provide some inspiration in helping you choose the right pattern you're after.

1

I have the same question as you. To answer yours (and mine) - the only guideline I found is the Google Page about Selection. Basically it says that long click on the list item "selects" the item - and moves the Activity into Contextual Activity Bar mode - where activity bar changes to reflect some editing possiblities to the "selected" items.

It is up to you what "edit" of the "selected" items mean. One obvious edit is the ability to delete - hence you see the trash can. Further if this one item can be edited with a separate activity - then you'll see a "pen" icon. If you select more than one item this "pen" icon will typically disappear.

To me it seems like too many clicks. So I am in favor of the long click to bring up the activity that edits the item. In the example you provided it what the Tasks app does.

One improvement I try to come up with is to make this activity look more like "contextual" editing. One way of doing would be only partially obscuring the original list - so it is not a normal activity but a dialog of sorts.

I did not do that in my app, though. What I did was my second option - namely style the ActionBar to look like CAB (contextual action bar). Notice that Tasks example has the logo, the back sign, and the accept and trash icons are on the left. Typically CAB has check on the right, with a different background, no "back" icon, no "logo" icon and other editing actions are on the left.

Technically it is not trivial to do. One advice I was given on StackOverflow is to force editing activity into ActionMode. That has drawbacks, too long to go into it here. That is the option I took though. Another possiblity is completely custom draw the ActionBar, which I assessed it too much trouble to do now.

That nicety aside, I'd go with the Task option in your case

1

As a hint to the original question that I have asked. It seems that the first two approaches works very well with a two pane layout system when running Calendar or Contacts app on a tablet. With these two applications, the right panel is always showing the view mode and there's no "Done"/"Cancel" button to pollute the actionbar.

An edit action then brings up the editor view which is fullscreen, even on a tablet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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