Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have an application I am designing and it's in a pretty functional state at the moment. But the database I am using has 1000's of items and is constantly changing and growing. The application of certain data items may vary depending on the user constraints as well (product interfacing with, user levels, etc..). I have tried to make this layout as flexible as possible to the point where the database basically controls the GUI layouts.

I would like to make this GUI as clean and easy to use as possible without having to redo everything when something changes. So basically....

What are some good approaches to making a dynamic/scalable GUI? If such a thing is possible.

EDIT- Good stuff so far, since you guys want to see what I am talking about, here is an idea. I have a SQLite database that contains fields for groupings and display formats and lots of other things which are parsed into a dynamic config tree on the left, and the tabs and groupboxes are all dynamicly generated from some creative SQL. There is a lot of data, so something generic isn't exactly a bad thing, since the complicated stuff will be hidden from less advanced users anyways. If the database is setup properly this could work very well I think.
I have a wizard as well which needs some work, but will make alot of this easier to handle since it isn't touched very often. But this all needs to be accessible without going through a wizard so someone can setup a custom configuration.

share|improve this question
    
The domain is a rather complicated, it interfaces to an embedded system which can be used by engineers to techs to lower level users. Our small company's primary focus is engineering, so user interfaces tend to be secondary. Even though the customers are surprisingly not too happy with what we currently use (hyperterminal!). –  radix07 Sep 1 '10 at 20:38
    
The screenshot looks pretty straightforward in terms of info architecture. The problem is that mapping an architecture 1:1 to a UI usually isn't the best solution. Instead, map the user's mental model of the architecture to the UI. –  Rahul Sep 2 '10 at 7:53
add comment

2 Answers

up vote 11 down vote accepted

I know what you're thinking when you say "as flexible as possible to the point where the database basically controls the GUI layouts", but this is a warning sign: you're going to end up with an app that is generic at the cost of usability. I see this a lot with "programmer UIs", where developers have extended their database and object oriented architecture into the user interface. Unfortunately, you often end up with a user interface designed for the programmer instead of the end user.

My advice would be to forget about looking for the ideal super-flexible, dynamic, scalable GUI and instead start identifying patterns of use you can design against. I'll be able to help you out more in this area if you provide more details (such as the domain you're designing for, examples, mockups, etc).


Edit: So, going by the screenshot you've added, it looks like the complexity of the database is spilling over into the UI. What I'm seeing here is literally a huge dashboard full of choices - I feel like I'm in Star Trek with the panels full of glowing buttons! Let me give you a quick first impression from myself as an outsider:

It looks like we're configuring something. By choosing an item to configure on the left, the right area updates with input fields corresponding to parameters that can be changed? But those input fields are themselves located within a tab, and there are so many tabs they're flowing off the screenshot towards the right. Also, the label for each field is cryptic at best: "Mx Ld Fct". It's nice that when hovering, you see a label that explains more, but do I really want to hover over different items just to find out they're not what I'm looking for? It's like an easter egg hunt. Further, it's not clear to me what "tools" does on the lower left. Both panes on the left appear to be maximizable, though I'm not sure to what effect.

I can sort of see where you're going with this, but I have to recommend against it. It's hard to explain why if you haven't gone through this process before. The best advice I can give is to grab some people who'll be using this right now and get them to use the app. Sit with them and ask them to perform some common tasks. Without commenting, just watch what they do and write down on a notepad what your thoughts are. You'll learn a lot. Try and do this every week, with the whole dev team.

share|improve this answer
1  
I think it looks like a lot of Oracle-designed applications. –  Angelo R. Sep 2 '10 at 16:10
    
The classic MMI conundrum...all the data must be available all the time and the number of data points for each sub-system is huge and ever changing...so you start thinking...maybe chewing my own leg off would be less painful. Sorry I can't offer much without more details but I feel your pain...You might consider a spread sheet type approach for your "I want to see everything." view with users being able to drag data from the spread sheet into a container for use in building custom layouts. –  Rusty Sep 3 '10 at 4:02
add comment

I have some points to consider:

  • Make sure long strings don't break the layout. Naturally I'm talking about the data itself, but the surrounding UI might also suffer. For example, consider a command bar with buttons. When the text on the buttons is translated, they might grow large and overflow the bar.
  • Make the UI "lazy load" some of the info and consider using pagination. For example, it might take too long to load at once thousands of items - make sure the UI doesn't look frozen or broken while it loads, or that you load one page and then load the rest while the user can also start interacting with the UI.

Otherwise I agree with Rahul that we need some more details to get specific.

share|improve this answer
    
Good points,the strings have already been limited within the database from porting the embedded side of things, so I will have the opposite problem in making them long enough to make sense. But your point is still very important. The tab layout seems to prevent the lazy load thing from being too big of an issue for now, but I do have a larger mass data editor that will only load 256 items at time until the user scrolls down far enough. Qt did that work though, not me... –  radix07 Sep 1 '10 at 23:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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