8

I am building an application where user's can create very complex widgets using a browser. The two main approaches I can think of to allow for this is inline editing and modal dialog boxes.

Unlike a simple text field, these widgets will probably have several tabs of information that they need to configure. One of the tabs will have to be a preview of the widget, and the others will be setting various properties and providing data to the widget.

In addition to all of these complex options, users can move the widgets around too, which means just about everything on the screen is interactable in some way if the widgets allow inline edits.

Popups have the advantage of letting the user deal with 1 widget at time, without thinking about the other ones, but I also worry that maybe they would feel disconnected from the other widgets on the page once they hop back. This does make the previewing of the widgets simpler though... and the page itself will resemble the actual product without all of the editing tools cluttering things up on the page.

Popups also make it easier to make a bunch of changes at once, and then bail out and not commit them. Inline edits could do this too, but then you'd have to present the user with dirty tracking UI.

The last consideration I have is that these widgets have a variety of types, and rather than provide a massive menu with 30 options, I wanted to allow users to refine the type of a widget while it was on the page. So for example, they put down a Media widget and can select from Image, Video, Audio, etc., and then they would allowed to do the inline editing for that type of widget. However this bares the complication that they can bail out of selecting the widget type while it's still added to the page... something the Modal Dialog would have prevented. I could either not commit that widget to the server, but it may be confusing since they did at it to the page... but untyped widgets would invalidate the data model, which also causes problems.

I am leaning toward dialog boxes actually, but I am curious what the best approach is. I am not a UI designer - just a coder.

Widgets 1

Widgets 2

Improve this question
3
  • they say a picture is worth a thousand words...can you provide a screenshot to accompany the descriptions you gave?
    – Chairman Meow
    Mar 5, 2014 at 22:04
  • I haven't built it yet, lol. I will past what I have.
    – egervari
    Mar 5, 2014 at 22:06
  • @ChairmanMeow Okay, I added a picture, although it's incomplete. You can edit the questions, text and other things. In the case of the question, there would be hints, keywords and all kinds of things that would need editing.
    – egervari
    Mar 5, 2014 at 22:10

4 Answers 4

Reset to default
8

Inline not Modal

Inline edit is to be preferred at all times. The user keeps context, have the ability to use information related and narrow to the edit and the user don’t have to focus on a new UI. It is the same, simple, easy and straightforward process where the flow of work can be kept.

Modal dialogue breaks the users’ context and it takes time for the user to focus on the new UI. On save you go back to the previous view and have to refocus once again. The flow in such a process is very frustrating, especially if you do many of these edits in a day.

Improve this answer
5
  • What are good UI patterns then for doing inline edits where the widget that you're editing has very complex forms... probably in the form of multiple tabs containing a form or some UI components in each one? For example, in my pictures above, you can imagine that the hints needed to be defined, the success message when you get the answer correct needs to be specified, all of the keywords need to be defined, there will be tools for adding synonyms and taking care of plurality, etc. All of this needs to fit on the screen somehow, so I can only imagine using tabs.
    – egervari
    Mar 6, 2014 at 7:17
  • @egervari If you need to fit it in one screen (without scrolling vertically) you should maybe try to implement show/hide content as an alternative to tabs. But that is really a matter of taste. Make two mockups and test on your intended audience.
    – Benny Skogberg
    Mar 6, 2014 at 7:49
  • So a bunch of widgets that have 3-5 tabs will be straight-forward to understand? I don't think show/hide will work in my case... one of the tabs must be a preview of what they are working on (probably the first one... like the way the widgets look in both of the screenshots. I am assuming then that it's okay to have multiple save/cancel buttons on each tab as well? Thanks so much for answering my questions. I am just a dumb coder, lol.
    – egervari
    Mar 6, 2014 at 8:17
  • @egervari Your question is very valid. And maybe you can make it easier if the user can use tab to go tom the next field, even if it's in another hidden section. The flow would be even greater! If I'm not mistaken in HTML its called tabindex. Good luck!
    – Benny Skogberg
    Mar 6, 2014 at 8:29
  • It's often a bad idea to pull up modal windows - but not always! As @BennySkogberg said - it disrupts the users work flow, but sometimes that's the effect you want! If the users enters a complicated view that differs from the original view, the change of looks could be helpful to let the user know that he/she has entered a "special place". In Photoshop, for example, when I accidentally press Q, quickmask mode is entered - something that I always overlook. Then I would prefer something that breaks my regular work flow in favor of knowing in what state the software is...
    – Henrik Ekblom
    Mar 6, 2014 at 13:16
7

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 optimally when you have something like a set of objects in a table that have complex attributes. The content of the table is primarily for a) recognition of target in the object set; and b) comparison across relevant attributes between objects in the set. For editing of objects or exploration of detailed attributes, a modal dialog is an excellent model for task completion. Inline editing would only be possible when the objects are simple and all attributes are shown in the parent table. So it all depends on the objects, their attributes, their relationships, and the tasks/actions you need to support in your UI on whether modal is useful.

Improve this answer
0

I agree with M. Anspach. In the past modal windows might have been abused for ads and other non-essential content. However, when utilized properly they can be the perfect companion for any complex application. I personally prefer using them for all "Create Record, Edit Record, Action Confirmation" windows that are triggered off of an inline record detail or record list view. Works like a charm, assuming that you are not overloading your modal windows with tasks that span multiple record types.

Improve this answer
0

It depends on the data what kind of action we want to do on that data. As an example to add regular but mass details can be done through inline. But edit the same shall be done through modal. So, user will have no effort to add more details and will have attention to edit the details.

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.