Calling all UI Designers for new Basic Skin

[tschak909]

Calling all UI designers to do the first phase of skin development, designing a replacement for the Basic skin.

Requirements:

* Must be able to understand capabilities of Designer and Orbiter, watch my screencasts.
* Must be able to work in a team.

Anyone interested in designing a complete replacement for all 5 major UI targets, please reply to this thread.

-Thom

[HorstJ]

Hi Thom,
I would be interested joining you team, but at the moment I try to get a java HADesigner running as I had more crashes with the original one as it is agreeable for me. Unfortunately I have less time at the moment so it could take some weeks to finish it... but then count me in 

[golgoj4]

Im in. I have been watching the screencasts and I would really like yo jump in on this.

-Golgoj4

[los93sol]

Is anything still happening with this?  I am actively pursuing this same goal, but could use some assistance from someone who is good with creating graphics and textures.  Thom, thanks for all you patience and work helping people get their heads around this system.

[tschak909]

This ticket is still open. Looking for people to work with on this... initially we need a complete aesthetic proof set done for all variations, which we can then build upon.

-Thom

[krys]

Count me in

[los93sol]

I agree that we need to get a complete asthetic proof down as Thom has said so the whole thing is well planned and executed so I guess I'll post my thoughts and the direction I'm thinking of going.

Currently the screens are quite cluttered with multiple buttons being repeated from one screen to another, as far as I can tell this could be cleaned up and reworked to eliminate all that redundancy and put the focus back on the media.  Instead of how UI1 and UI2 are currently laid out with everything available from the main menu I'm thinking it should be physically laid out in different windows.  Combine this with the way UI1 organizes the categories in a vertical manner and the main menu issues would be solved.  UI2 is nice but has a lot of unnecessary information displayed and placeholders for it the remainder of the time.  This issue I think could be addressed by having a "header" at the top of every window and creating an invisible button in this header so that any time the top left corner of an orbiter is clicked/touched, etc. you are taken back or possibly always taken back to the main menu.  Using this method we can get rid of another button and clean up the screen real estate.  Just some ideas I've been playing with here, but since I'm not so good with graphics and textures I don't exactly have something beautiful.

I'm also curious to play with the media windows and see what kind of tricks can be pulled off on that as I don't like seeing both covers and a list at the same time, it doesn't make sense to me...I'd rather choose to see the files one way or another, but not both at once.  The covers are nice and I'd like to push the list off the screen if it has to remain then expand the covers so they take up the whole screen...the obvious issue with this is that you cannot scroll the list, but is it possible to create a button to scroll the list?  If we could do that then the bottom left and bottom right corners can have invisible buttons or a small graphic with a much larger transparent button to accomodate touch screens etc.

Just some ideas I've been toying with and playing around with to find a good layout that looks elegant and stylish to fit all variants of orbiters.

What are you guys thinking about doing?  I wanted to post this so we can find the happy medium and get a plan together since we'll be working together on this and am not convinced that I have it all figured out so let's get some discussion going so we can make some progress

[tschak909]

Yeah, let's start just throwing up some layout bits, even if it's just squares with placeholder text at the moment, so we can get a sense of space.

We do have the ability to do popups, but we have to be  very careful how they are used, particularly:

* Popups are not composited with the rest of the display in UI1, basically, alpha is ignored. Again this goes back to the fact that in Orbiter, everything is pre-rendered. and most importantly, any transparent areas are ignored, so popups need to contain all opaque pixels, otherwise you see black.

-Thom

[tschak909]

In the INTEREST of trying to get something done, we may want to split this into two distinct goals:

* Phase 1: Simple skin-graft for UI1 and UI2.
* Phase 2: Re-lay out of Basic

The reasoning is very simple,

We should get something done as quickly as possible to show progress, but FURTHERMORE, this will show everyone involved the effects of graphic rendering in orbiter while working on our own stuff.

Why am I bringing this up specifically? Because of the way Orbiter renders its graphics:

1. They're pre-composited.
2. They're pre-scaled.. (read that one again)... So hair-thin lines etc, WILL DISAPPEAR if you're not careful.
3. We'll be able to test the simpler ideas so we don't waste months with nothing to show.

-Thom

[krys]

Well, in my short experience with LMCE I havent had a chance to set up all of the home automation stuff yet. The problem is I dont really have a solid idea of the best layout since I dont use all of the functions regularly just yet. Maybe we should start by deciding which buttons we actually need on the menu make a list(so we dont leave one out accidentally) go from there. I am not sure that I can recall what buttons are on the menu now, and I am at work so I can get on HAD atm.

I am willing to take some rough sketches from someone and turn them into pretty design pictures so we can have something to look at for the different concept models.

[tschak909]

I use virtually ALL aspects of the system.

If I hadn't already bought christmas presents for my family, I would pay for a conference, so that I could show you my entire setup.

-Thom

[tschak909]

Something to keep in mind.

The name of the game here, is balance.

Yes, reductionism is important when laying out a UI, I am a happy believer in less visible is more...

HOWEVER...

Keep in mind that if you hide something in a menu, that means you have to SHOW that menu. This typically translates into more button presses.

So yes, finding the things we use most, is important.

I have the following orbiter surfaces:

* On screen display in Bedroom, with Fiire Chief, MCE IR, and Gyration Go Mouse 2.4's as remotes
* Five WebDT 366/360 tablets running PadOrbiter. The two main ones I use are in the bedroom, and the Kitchen. I also have one in the bathroom.
* A Cisco 7970 Phone orbiter at my main laptop's desk
* A Nokia N810, which floats around everywhere
* A Nokia N70 phone as my Mobile Orbiter
* an iPAQ 3115 Windows PDA for testing the PDA variant.

So I can test just about everything in a real world setting.

One of the things I can tell you, is to record your interactions with the system, make note of how many times you press buttons to do things, and the choices you have to make, for example:

I did a rough interaction log in one 6 hour evening, and found:

* I went into videos 18 times
   * I searched for a video using search 2 times
   * I searched for a video using a detail filter 9 times
   * I searched for a video with no filter 6 times
   * I searched for a video using just the high def media type 1 time (because I knew it was an HD movie)
* I went into audio roughly 7 times
   * I played a playlist 2 times
   * I played an entire album 2 times
   * I played a filter selection (genre: ambient) 1 time
   * I played individual songs, 2 times.
* I changed lights in the bedroom 3 times
* I changed lights in the foyer using the floorplan, twice
* I used follow me for media, once to bounce media from the bedroom to the kitchen
* I used the computing section 3 times to browse sites.

and so on.

Maybe not this detailed, but to give you a mental picture of what you're doing to make yourself aware consciously of the steps you are taking to do a particular task.

-------------------------------------------------------------

A Note about Button Arrays

much of Orbiter's functionality comes from the fact that user scenarios are dynamically generated. Read that again and burn it into your skulls.

To give an example, there is a utility that runs in the background called UpdateEntArea. This little utility takes stock of ALL of the devices in an entertainment area, and figures out what buttons to add to each category on the main page:

Some examples,

Media:
* If a media director is present in a room, TV, Audio, Videos, Docs, Playlists, and any buttons for legacy A/V control are added to media.
* If an optical disk drive is present in a media director, the Manage Drives button is also added to media.

Lights:
* If there are any lights in a room, On and Off scenarios to turn all those lights off at once are added.
* If there is a media director in a room with lights, Showtime is added so the lights can dim. An event is also added to trigger showtime when media starts.

Climate:
* If there is a thermostat ANYWHERE in the house, buttons are added to turn it on and off.

Security:
* If there are any sensors that can be armed, an Armed event is added, which triggers a scenario called Leaving Home, which turns everything off in the house.
* If there is a camera, it's added as a button

Some future examples might include:

* If game ROMs are present in the games directory, the Games button is added to Media
* If you are in the kitchen, a scenario is added to show recipes.

and so on.

Point being, The number of buttons and everything changes depending on what is available, and you have no way of statically controlling these things in a maintainable manner. This is where arrays come in..

arrays are merely areas on a screen where Orbiter can lay out in a grid like fashion sets of designobjs (usually buttons) which are populated by the various plugins. Because arrays are sets of designobjs, they are generated as part of the orbitergen process.

........

I hope I've made it clear, that we have to think way beyond the realm of just trying to make a pretty picture, and that we have to be very holistic in our approach. We have to be aware of the moving parts in this system and know that they all react to one another.

Some stuff to think about,
-Thom

[krys]

well, I think I am going to sleep on that....

[los93sol]

Thom - Absolutely you are spot on and that explanation will hopefully help serve as a reminder to anyone following this thread that we are up against more than creating a graphically stunning UI since LMCE does so many things dynamically to improve its own usability.  I had understood this prior to this posting and have put together a VERY rough layout in paint to demonstrate what I am thinking about doing.

Along with your notes it is also important to fix current nuisance issues such as LMCE's status popups whenever it is doing something in the background, it currently can cover up several elements of the UI which can leave you blindly navigating in some instances.

A quick note before reviewing my draft, I am proposing that this layout be used throughout the UI and that it stay consistent so it is never confusing to the user.  This layout provides for an unlimited number of scenarios to be added while staying consistent to the UI design and eliminates the current issues where labels do not always fit on buttons completely.  Please give some feedback on this design as I do think that it is at least close to what we need to meet between function and form.

[krys]

** Krys rubs his hands together with anticipation... or maybe it is because my office is frickin cold**
Lets see it, at least it will give us a starting point


anyone started a wiki for this yet? might be beneficial to have a place where the information is centralized so once this thread gets to about 30 pages we wont have to scroll through the whole thing.
I am thinking at least a list of items that we would like to change, such as the annoying pop-ups, I personally cant stand the text extending past the edge of the buttons...etc