5.0 Previews Thread

[Dean Roddey]

So I just wanted to start a thread to provide previews of 5.0 work, so that everyone can see where it's heading, and comment earlier and more oftener as they say. I'll keep this thread updated as things move along.

The big change for 5.0 is a complete rewrite of the user interface. That's a huge thing to take on and it's not being done lightly (it's stupidly heavy in fact.) But we really needed a more modern, consistent user interface. That, unfortunately, meant throwing away not just years of work on the existing interface, but throwing away all of the custom UI widgets that I'd created, which were even more years of work.

Obviously we can't wait more years for the replacement, so the strategy is two fold:

• Use the built in Windows user interface elements, just encapsulate them into a class framework. It will be as similar to the old one as is reasonable, but not to the extent of limiting our ability to take a huge leap forward. I.e. it's not going to be the old interface implemented in terms of a new underlying windowing framework, hence #2.
  
• Start from the be beginning with a very standardized look and feel in mind and implement the functionality required to make it possible to achieve that with as little effort and redundancy as humanly possible (and a little inhumanly if we can pull that off.)
  

This will involve a number of big changes such as:

• A move towards a tabbed interface with a tree style browser on the left. This is pretty similar to many standard Windows applications.
  
• Get rid of as much modality as possible, meaning way fewer modal dialog boxes.
  
• Integrate the CML IDE and the interface editor into the main admin interface. The driver IDEs might have to wait until post-5.0, but that remains to be seen. Still, it'll be a big step to get almost everything into one admin client. And some other smaller tools will likely be incorporated as well.
  
• Support copying, pasting, renaming, etc... stuff (templates, images, macros, etc...) within the tree browser, which is stuff that is now fairly annoying to do.
  
• Move very much towards 'edit in place' interfaces, and a standard 'attribute editor' type scheme for editing things like template widget attributes, instead of modal popups and dialogs.
  

One non-UI oriented change that the above (tree browser orientation) will force is that now everything will have to move to hierarchical storage. So things that weren't, like schedule/triggered events, will be updated to comply. In the process, I've also consolidated a huge amount of back end data server functionality into a more consistent, integrated form, since it all now has to be accessible via a single, comprehensive hierarchy.


I'm going to start keeping the most recent previews posted here in this thread, for folks who just want to see the latest and not read through the thread.

Latest Admin Client Progress
http://www.charmedquark.com/Web2/PostIma...eview8.wmv

New Stuff Since the Above
http://www.charmedquark.com/Web2/PostIma...eview9.wmv

And Newer Stuff (driver management)
http://www.charmedquark.com/Web2/PostIma...view10.wmv

A previous version but with more CML IDE details
http://www.charmedquark.com/Web2/PostIma...eview7.wmv

So take a look at these and let me know if you think this is a step in the right direction.

[znelbok]

Its looking good Dean - I like it so far. Using it will be the ultimate test though.

Can you tab between fields (on the right)? To have to go to the mouse every time you want to type a value in can slow you down. Also, using F2 to go to edit mode for the property that is currently selected (like excel) would be great.

I have mentioned this before, lets take the example you used for the true & false selection (and it may not apply here directly but for the example it will do.)

Lets say its for a widget in the template and there is a true or false field. Instead of being constrained to True and false, allow an expression (that must result in true or false) to generate the true/false.

i.e. if (moniker.field > 60)

That way it would be true some of the time and false some of the time, but give extreme flexability to the configuration of the interface.

This should exist for all fields, where the expression must result in the data type required

e.g. for a string field

if (moniker.field > 60) then "time to do something" else "Level OK"

You already have the interface for generating the action statements, just apply that to the property fields (I make is sound simple, but I am sure its not)

Mick

[Dean Roddey]

You can arrow up and down through the list. I'll implement the edit mode key as well. For the two selection only schemes, the edit key would just drop down the menu for you, so you arrow to the one you want and hit enter. So you wouldn't have to use the mouse at all if you don't want.

The other thing, not likely to happen, at least not for 5.0. The user interface is going to change, and various internal improvements will be made to support the new interface (which will be a lot more abusive of the back end if it worked the way the UI does now in terms of getting info.) But, beyond that, I've already bitten off enough to choke me to death, so best not to make it worse.

[Dean Roddey]

Oh, BTW, I forgot to demonstrate another nice feature, which is the 'ad hoc in place editing', which can be supported anywhere it makes sense. For instance, in that loadable text selection dialog, you can click on the name or the text content and edit those in place as well. Anywhere there's a list of that sort, the parent window can enable that fairly easily where it makes sense. That'll make it pretty low overhead to allow for editing of lots of stuff.

[bbrendon]

Nice. The standard file -> open dialogue box!
I'm sold already.

[jkmonroe]

i like it. very neat and clean, easy to understand.

when we're using this new scheme to edit, it looks like widgets would be single-clicked to bring up their properties. will a double-click do anything?

[Dean Roddey]

Double click wouldn't do anything anymore. There will still be a right click popup menu for some things like forward/back, front/rear, and a few things like that, things that aren't settings but actions.

[dlmorgan999]

I definitely like what I see so far Dean - it looks like it will be very nice to use!

[DaveB]

Great job Dean. You are on a very good path.

[123]

I'm not a CQC user but I like what I see in the new UI. Kicking modality to the curb is the right thing to do.

Comments:
If I understand the video correctly, fields whose values are selected via a dialog-box are indicated with a "?".

First, the convention for indicating this mode of operation is typically the ellipsis "..." and not the question mark (normally used for help).

Second, it is not needed. I see no utility in revealing which properties use dialog-boxes for entry and which don't. The feature occupies an entire column in the Property pane to show superfluous "meta-data".


Suggestion:
At the risk of sounding like a broken record, here's how it is done in Premise. When the field gets focus, an ellipsis button appears in the field. Click the button and the associated dialog-box appears.


"Group" is filled using a dialog-box.

Another way would be to display the dialog-box after the field gets focus and is clicked. This is how you have implemented fields using dropdown lists; you click to reveal the dropdown so why not simply click to reveal the dialog-box?

FWIW, in Premise, dropdown lists use the same technique of "get focus then show button".


"Access" is filled using a dropdown list.

I don't know if fields in CQC have associated descriptions but if they do it would be convenient to have it displayed.


The description for "Preset Dim Level" is displayed at the bottom of the Property pane.

BTW, Premise's Property panes can be resized, hidden, snapped, floated, and pinned. In practice, I have found resizing to be the most useful ability followed by hiding one pane to provide more real-estate for another. I normally leave the panes docked to the sides. Float/snap/pin <shrug> are features I have not used often. I think resizing and hiding are adequate.

Premise's Property pane also lets you display properties grouped by category or sorted alphabetically (using the buttons at the top of the pane). It's a convenience feature I have found useful on occasion (lots of fields and you know the field's name). Most of the time I leave the properties grouped by category.

One last thing: you'll notice some properties are modified directly. For example, "Brightness" is adjusted by clicking or dragging. "PowerState" is a checkmark box. "Brightness" could've been exposed as an Integer or Real value (it is actually stored as a Real value) and "PowerState" as a dropdown list (On/Off or True/False; it is stored as Boolean). However, I guess for purposes of speed and convenience, they are accessible directly (to minimize clicks).


All in all, a very promising first step and I look forward to seeing the next iteration. Good luck!