Hot answers tagged

4

This can be done a couple different ways. 1. Sample Values as placeholders If your fields you can set default values as placeholders <input type ="text" placeholder="John Doe">. This will give your users immediate context in what data you want them to fill out. The placeholder is typically a lighter color to give it a "ghost" effect of what content ...


3

I think you can get close with just a couple of changes from where you are now. Have a different and informative CTA for the requirements Currently you have 'Save' (local) and 'Save all changes' (global). This seems potentially confusing. If you changed the CTA to something like the following, the user would be made aware that this change is local, not ...


3

I think modal could be an overkill, as it will take the focus away from the page - and moreover its not justified for something like an edit function in the context of the application. Take a look at the below suggested flow: 1) Initially, the user is visually shown which are the editable vs non editable categories. As seen, Reqs are shown to be editable, ...


2

You might want to look at how Google's Material design solves this with its concept of chips. So in your case once the user links to a person, it is displayed on the screen as a chip. The user can could then remove the chip (unlink) or add a new chip (link a different person). Here's a link to the design guide on chips: Google Material Design Chip ...


2

How about one tab for each object you want to create?


2

The user may be completely missing the checkbox and text, since it fades into the footer of your modal. There is nothing calling attention to it. I would try two distinct buttons for saving: "Save and Add Another" and "Save and Close" (or just "Save").


2

Hmm... good question. Personally I would find it intuitive as all other elements worked the same way. I'm assuming on hover you also show the word "EDIT", if not , you should. One thing to try is in the read only view, add a last line to the view in smaller font [V] option 1 [V] option 2 +3 more unselected options... It would help if you explained the ...


1

Let me see if I understand you (because I think you're overthinking the problem). As a user I want to associate a person with an item. I look up a person (Josh); think I have the correct information and then realize that I have the wrong Josh and start to edit the information. (Or maybe I have Josh's updated phone number and the system is out of date so I ...


1

This is a more common problem than the number of questions that have been asked about it, so I think it is a good place to summarize a couple of key points that may help you to determine what the best combination of strategies might be: Labelling of the call-to-action: the wording that you use can play a small part to address this issue. I know that people ...


1

"The earlier system just had all fields editable at all time, which avoided this problem - is that still the best way to go?" Yes. What is the difference between the fields of a requirement to the fields of its evaluation? - None. The evaluation fields are also "saved" locally and you do not have 'Save' and 'Discard' buttons for them, and that's because ...


1

The solution I would use here is fairly simple- pull out the nested edit unto a modal window. I've also made some modifications to try and address some of the slight UX issues in the original mockups. download bmml source – Wireframes created with Balsamiq Mockups (Pretend that the above mockup is presented beneath the grey overlay) ...


1

What is the ultimate goal for the user? Evaluate the Law? Edit the Requirement? Edit and Evaluate? I suspect the ultimate goal is to just Evaluate, and if so this should be the primary Call to Action trigger. I also suspect that Editing the Requirement is an occasional supplementary activity so it's trigger needs to be very different to the primary ...


1

I'm a big believer in the Keep It Simple Stupid (KISS) principle. Assuming you have to keep the basic design (i.e. the table with accordion expander), one of the main things you have to consider is the workflow of your users. If the majority of the time users would only be expanding the selection to view it, then I would leave it as is. On the other hand, ...


1

Not to get too meta here, but how about the approach used on ux.stackexchange? Using these two buttons Save Edits and Cancel would allow you to meet your requirements. Additionally you could disable the Save Edits button until an edit has been made. Applied mockups: Before edit: After edit:


1

The best I've seen is the input you selected (type in entries with commas) which then turns into tags, a la gmail. That way every comma entered creates a tag, and in theory removing the comma brings back the text (though that's technically more complicated). It provides a really simple UX with no real training, except that people are currently used to the ...


1

There's 2 factors to think about when deciding which type of editing format to use: Speed of Update and Complexity/Dependency within the data. Speedy entry of simple independent data: use Inline Edit If speed of updating individual pieces of information is important, then inline editing hands down beats editing sections. User can click into the section ...


1

I see a number of potential issues with that spell checker/corrector UI. One issue is that it clutters up your text, your (possible) errors are much more front and center than the traditional underline that indicates a possible spelling error. With the correction suggestions inline it interrupts the flow of the text. With the corrections interline it ...


1

Disrupt the flow as little as possible I agree with you that inline editing is the way to go since it provides context to what the user is currently looking at. I don't like the idea of automatically changing modes when selecting a row since just this can disrupt the user's flow and is more prone to accidental edits. I would combine your first and last ...


1

These comments about modal dialogs "interrupting workflow" are silly and naive. If you build your parent screen and modal dialogs as symbiotic parts of the overall task process, there is no interruption. All complex operations have to be broken down into steps or "consumable chunks of task" no matter how you build the design for simplicity. Modals work ...



Only top voted, non community-wiki answers of a minimum length are eligible