9

I notice on this particular page in Basecamp that they have two different buttons that are meant to save changes to two different sections. One section is above the fold and clearly has a "save changes" button. The second section reaches far below the fold and has a button at the bottom to "Update project access." But the first button looks like it works for both sections, especially if you don't realize there is a second button.

So, what would be a better approach for this page? If your main navigation already includes two sets of tabs, how do you break a sub-page into sections that make sense to the user?
(Assume that each section must operate separately because they use different parts of the database.)

Basecamp edit user page

Improve this question
6

7 Answers 7

Reset to default
4

I think of these mass interfaces as a great chance for the technology of today to come into play.

1) No save button ANYWHERE on the page. All of your information can easily be saved through ajax calls by jQuery to send the update commands to the servers.

2) At the end of each box you can display the little spinning icon to show that the changes are being made

3) End with a "Done" or "Finished" button at the end of the page.

Now to tackle the really long side bar, once again using jQuery once the top level is clicked the secondary levels show.

Improve this answer
2
  • 1
    I like the auto-save approach for binary inputs like the checkboxes, but for text entry, I'd be worried about saving every (non-correct) increment on the way to completion. For instance, let's say the user is updating their login email address, and their browser crashes halfway through typing it out. In my database, I could now have a malformed email address, and the user wouldn't be able to log in. Of course, with email, you can do some data verification, but for true free-form fields, you can see where this would be problematic.
    – Daniel Newman
    Jan 23, 2012 at 20:14
  • 1
    Hi Dan, you would combat that problem by not saving the field until the onBlur event of the input or jQuery .focusout(), instead of the onChange events. However if the browser crashes the currently call to your database would not succeed as it should stop at getting no response.
    – James Wilkinson
    Jan 24, 2012 at 17:28
2

Ideally redesign it so this doesn't happen.

Could one thing just auto save without user input; do they really need to be on the same screen?
Could you turn this into a few screens that leads them through what they need to do?

Failing that I think the best you can do is to try to show visually what content is paired with which save button.

Its also important to show which chunks of the UI have unsaved changes and need to be saved.

Improve this answer
1

Interesting, suggestion:

  • I would suggest changing the label (to Update project access) and the color of the button after user hits the "Save Changes" button and as the user clicks it, the page navigates to the referred section on the bottom right hand.
Improve this answer
1

One solution is to have a save button at the top as well. Duplicating buttons is not really a problem technically, and if the page is liable to be large, this makes sense. Even when it is actually small, having two buttons is no real issue.

Taking this further, given that the bottom of the list is open ended, having the process buttons at the top as a whole would be a better option.

The other route is to colour areas when they have changed, and re-colour when they are saved. THis has to be done very carefully though.

Improve this answer
4
  • Would you be interested in joining the Cognitive Sciences stack exchange site? Human Computer Interaction is considered in-scope. (couldn't find another way to reach you)
    – Ben Brocka
    Jan 24, 2012 at 21:44
  • @BenBrocka - yes - when it lets me.....
    – Schroedingers Cat
    Jan 24, 2012 at 22:38
  • If you mail to the email in my profile I can send you back an invite to the private beta...I think
    – Ben Brocka
    Jan 24, 2012 at 22:40
  • I would if there was an email in your profile. send me on [email protected].
    – Schroedingers Cat
    Jan 25, 2012 at 8:59
0

The problem at hand is:

How can we contain the height of the right sidebar when we don't know how many projects there could be?

Solution 1:

Add expand/collapse buttons to the project titles to show/hide sub-sections. However, even this way project list can grow below the fold hiding the Update project access button.

Solution 2:

List the projects, to which the user has access, and offer permission editing on a separate dedicated page. The link to editing permissions should be next to User has access to.... This adds another page to application views but removes all ambiguity of what control relates to which element.

Improve this answer
0

If I understood the censored screen correctly, the main section enables editing the users' details, whereas the long and narrow section to the right enables editing the users' rights/roles/access.

  1. It seems counter intuitive to me that each has its own save - especially since they are on the same page (different tabs would still count as same page).

  2. If the input is long, you should auto-save input, yet if the affects of the save are either drastic or not undo-able do not "apply changes" until the user presses a button. Just because the two sections update separate databases doesn't mean that the two saves have to be initiated by separate user actions.

  3. A long narrow section as you have to the right just looks bad. Instead use a tab for this with a display filter (typing in a few letters to reduces fields) and paging (e.g 20 rights per page).

  4. Your division to regions and tabs seems unintuitive... You have 4 different menus:

    a. Launchpad, base camp projects

    b. My info, Sign out, Help

    c. Dashboard, TODOs, Calendar, Time

    d. All people, search, templates, settings

I have no idea what (a) is for, so I will ignore it.

(b) seems ok where it is, people are used to accessing log in/sign from the top-left corner of pages.

I think that (c) and (d) should be united somehow. The relation between them is unclear so I can not elaborate on how.

Improve this answer
0

I would imagine that the options would be to have either:

  1. Autosave + one save button to rule the whole page.
  2. One save button to rule the whole page

Deciding between these two would in my opinion require usability testing/workflow analysis/further knowledge about how the app works in general. There is pretty much no real reason than perhaps some bs technical reason that the whole page does not follow one save button. If everything else in the whole site autosaves, I would add autosave, but still retain one save button (because with textfields it is hard to be sure as Daniel Newman pointed out in a comment to another answer).

The one save button would have to be above the fold. Otherwise it risks not being noticed.

Improve this answer

Your Answer

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

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