Interface Design and UX Thread - How our App Looks

[angelize]

I like the Gear interface. I took Barbara's file and gave it a grungy metal look. All the pieces and parts and a couple of really nice textures as well came from the scrapbook section of the DPX designs gallery. I modified them a bit to fit Barbara's basic idea.

[Barbara B]

I like what you did.

I especially like the current tab displaying in a metal nameplate or gauge window, the addition of the screw heads.

I didn't texture the gear, especially the center panel because I thought it would make the text hard to read, but your treatment separates beautifully.

[Rik]

Are we settled on the Wheel, or is it worth considering a different look?

Obviously, the colours can be changed to suit.

[PeteS]

Personally, I really like Rik's design. A good, clean, clear UI. And more importantly is scalable if new options are needed in the future, the UI design doesn't need re-vamping.

Barbara's design bought back memories of Webstyle 4 for me with the layout of the sections (except the editing options in the middle). Nice design and some good designs it's inspired Gary (I like the white on blue design) and Francis

As this project is in a fledging state I think that getting the basic functionality of the program figured out is the first step, and even just the functionality implemented for the first release. That will give us an indication of the specific requirements of the UI (eg how much space is needed for each section, how many sections etc). Also, the UI is largely superficial - it's a skin that's applied. Much like changing your CSS on a website (OK, may be it's a bit more work, but you get the idea).

[Gare]

If all this does is serve as a reinforcement that the tg community is behind the project and behind Grace, I feel it was an effort worth expending.

Yes, Pete is dead-on: skinning is trivial compared to the coding, but it is nice to see both cooperative and independent ideas being brought up.

Food for thought!

-g

[gracehjs]

The actual coders decided that we would like to start with a basic design and get the functionality there. I actually like RIKs take better initially for the content. I would like to add a field for each item that showed it had been changed from the default value - I think this would be helpful.
Plus, as I pointed out this is a standard windows app and as such should have the standard controls for menus. Look at the one I proposed.

[mwenz]

Grace,

Design by committee is rarely efficient and at this stage is rather distracting. Having done large-scale programming in the past, I feel you are on the best track to make it functional in all aspects, followed by likely reorganization (moving controls to different tabs, renaming controls, etc.), and then gather all the ideas on appearance and making a decision as to where you take it.

If I were the programmer here, I would leave the appearance-oriented threads to develop and probably not even take the time to comment on them. It is incredibly premature--but then, appearance issues are the easiest part for most designers.

Mike

[Barbara B]

Hi Grace, Steven, Pete and the other programmers,

I think that part of the communications disconnect we are running into here is that of jargon and viewpoint.

When Grace talks of Standard Windows Program, I'm sure that has much more meaning to it than what comes across to the non-programmer. You see, from a non-programmer's viewpoint if it runs on Windows it is a standard Windows Program as opposed to a Web app or a Macintosh program.

And it gets even more vague, because a lot of Windows 8 stuff looks a lot more like a Web App or a Mobile app. And Windows Desktop apps themselves have had lots of different looks over the ages and were sometime more dependent on what the coding/authoring system was than the OS they ran on. Think of all those Borland-built shareware apps - you could spot those a mile away.

The expectations of what is feasible or desirable also vary. The backend/programmer's viewpoint is quite different than that of frontend UI developer and both are very different from that of the customer/enduser. See endless debate on the why and the how of how dark vs light interfaces are coded, changed and used. And everyone of these three groups think that their job/use is the most important and that the project should start and flow and be based on their viewpoint.

But both the front and back end team have to work together to generate a great (or even adequate product). It does no good for the front end designers to deliver a design that is unreasonably hard to implement or maintain or scale. It does the programmers no good to do their work without a clear idea of what the output, the presentation will be. And user's, particularly the artistically inclined, won't use the product if their needs for functionality, dicoverablity and over-all aesthetics aren't met. And programmers won't program if their basic needs are not met and their voice is not heard and neither will the graphic artists, document writers and promotion-minded members of the project.

So to the programmer's I ask, what are the requirements for a Standard Windows Program?

If the rectangular program window ( not a floating app) includes:
1. A title bar: Program logo --> Program Title --> Minimize Restore/Down and Close buttons
2. A menu bar: with File Help About
3. Content Window ( the space between the titlebar/menu and any vertical or horizontal scroll bars or status bar.

A. A Background similar to the pasteboard background layer or body background on a web page or wallpaper.
B.The multi-page form field that contains the options that the user will select or deslect or otherwise modify.
a. The form itself uses check boxes, sliders, drop-down, list boxes, form entry fields etc.
C. Controls for the form - choose which form page displays
D. Some kind of control that chooses which program's registry options are being worked on.
E. Some kind of control buttons like OK Cancel Apply Finish etc.
F. Maybe tool tips or information buttons bringing up context sensitive help or just a help or support buttons
G. Status Bar

Questions - must the the form field B be rectangular? Microsoft's Page, Changing the Appearance of Windows Forms has a section on How to: Create Nonrectangular Windows Forms and other forms related info. Would creating a non-rectangular form be possible given the programming tools you have or is it unreasonably difficult?

The controls within the form field (B.a) do they have to be the default ones provided by the OS or your programming library or can custom ones be used. Again, once custom looking sliders or check boxes or toggles are designed, and provided to the programming team in whatever formats and sizes they need to be, are they unreasonably hard to use and or maintain?

Pete brought up the idea of scaleablity. I can see where having the controls in a circle could make it difficult to add new tabs. New artwork at the very least would be required (although I think you will always have a stable of capable and willing artists available), but I'm guessing that the coordinates would also have to be adjusted in the code which adds complexity. So...

Is it possible to have a vertical list of tab buttons that is not visually attached to some kind of non-rectangular form field display. And could those tab buttons have a distinctive look the way web menus can?

Once some of these questions are answered then I think the design part of the team can come up with reasonable, but graphically interesting designs that meet programming needs.

Good Programming takes time and it doesn't occur in a vacuum - that is understood. But good graphical interfaces also don't happen overnight. I truly believe that they have to evolve side by side.

[Barbara B]

Sorry the thread was closed inadvertently. I've reopened it and it is operational again. Sorry for the inconvenience.

[pauland]

The actual coders decided that we would like to start with a basic design and get the functionality there.

As a coder myself, I'd say that it's a mistake to not get that design done before making something that gets seen by the community (what the coders make for testing and never gets seen is immaterial).

My development uses the MVC pattern, so the actual look doesn't matter too much, but I can build the functionality without knowing what the UI looks like.

I guess you guys need to know what tabs/sections will be required and what options can be changed. The coders can build that functionality and the UI can be made to reflect how the user interacts against that functionality.

Get the design done properly. Reduce complexity by only implementing one tab/section/.., then build on it.

If you don't finalise the UI and functionality first, it will turn into a lot of grief to change it afterwards.

Better start with something you're proud of from the get-go.

It's not a race, is it?