I am reviewing Allon's patches (e.g. http://gerrit.ovirt.org/#patch,sidebyside,2188,11,backend/manager/modules... ) and this is the first time I have met @SuppressWarnings("synthetic-access") annotations in the ovirt code. It is right, eclipse warns about the performance problem synthetic access (if turned on, by default it is turned off). This mostly happens in DAO's because rowmappers are private inner classes. What if, instead of adding an annotation to ignore this
- we could make the rowmapper classes package protected?
- or since most of these classes are stateless and thread safe, we can add a public final static rowmapper instance and instead of instantiating the rowmapper over and over again, use that single instance.
Please share your thoughts.
I recently had to use the Engine UI (GWT one).
The UI in my opinion is very unintuitve and, at some flows, even counter productive.
It took me a lot more time to figure out how to do even the simplest tasks.
Lets start with the rudimentary things.
These are agreed upon UI idioms that are not used currently thus causing needless confusion.
These idioms are ingrained into how users grasp a UI when they first it.
I did not invent these they are written in various Windows\MacOS\KDE\Gnome and many other UI\HI guidelines.
This is not a complete list of all the problems, just the things that annoyed me the most.
* Buttons\menu items that spawn dialog windows should end with an ellipsis ("edit..." vs "remove").
* Grayed out means disabled not "not selected" (eg. the domain creation dialog->the lun chooser).
* Never write things vertically only horizontally (eg. the domain creation dialog).
* The entire object be clickable not only the text (tabs).
* Clickable items should be either underlined in another color, or inside a box to differentiated between regular text (menu items).
* Buttons should be in the same group should be in the same width and height and the entire area clickable.
* Border toggling cannot be used as hover indicator only background and/or text color toggle.
* Don't use "/" in the column header."host/ip" should be "Host address"
* Everything should be arranged in relative proportions (The search bar looks weird on large screens)
* Everything about the error message windows
* Try and scale the browser window to 800x600 and see what happens.
* Icons that don't have text next to them have to have a tool tip (bookmark search icon)
* (This one is my personal preference) Everything that is clickable should have hover toggle that shows what is the entire object you are clicking.
* Color scheme!!! alerts(red on gray?) Where does the green on the logo fit into all of this?
There are tools to help you create an eye pleasing color scheme (eg. http://colorschemedesigner.com/)
Now that the basics are out of the way. These are my opinions and are debatable.
- Top panel:
* current user name should be next to the sign-out not on opposite ends of list.
* About and guide could be merged to "help" Non of them deserve that much prominence in the UI
* Configure? What who? Find somewhere contextual to put it.
This is a long standing gripe against the UI.
* First and foremost it doesn't work properly. Try navigating the Tree and then editing the search bar.
* The browser already has a bookmarks feature so reusing the name is confusing, maybe saved views? perspectives? I don't know.
* The search bar is change when I navigate, This is confusing. Imagine having the gmail search bar change when you navigate gmail.
To fix this I suggest that the search bar remains empty unless the user starts using it and the bookmark button moved to a place where it's obvious it relates to the current view\perspective.
- The Tree
* Tree? Really? Is that a proper title?
* Tree refresh annoyingly does collapse all
* What is the difference between the button on the right and the one on the bottom?
* I'd rather it'd be called log\messages because these are not really events
- All tabs
* The difference between "guide me" and "edit" is confusing and arbitrary.
* Buttons in the toolbar should be grouped, and spaced according to those groups.
* Buttons should utilized the above general UI guidelines
* Similar buttons like "run" and "run Once" or "new desktop" and "new server" might be better displayed as drop down button (http://bit.ly/xMAUbK)
* Stuff on less importance like "change CD" could be grouped under a drop down button as well so it's less cluttered.
* Paging is so 2000, everyone does continues scroll now (http://bit.ly/a8B9UC).
- Guide Me:
Does not guide and is utterly confusing.
* Some buttons are grayed out but you have no idea why until you figure out that there is a hint hidden in the tooltip (An allusion to XKCD?)
* Can't use existing entities! Only create new ones. Why?
* "Optional actions"? Really?
* "There are still unconfigured entities". What? I don't understand what is wrong. Unconfigured isn't even a proper word. Do you mean that I still have entities to set-up? What entities? What is an entity?
* "Configure later"? What is wrong with "close".
* Again, unify with edit, I kept clicking edit even after I realized that I need to click guide me.
* The green line under the black part of the top bar is just annoying.
* CPU Name -> CPU Architecture( name)?
* destroy (in storage domain) -> force remove
There are a lot more things that could be stream lined.
The lun selection screen for example is just plain confusing.
But that would require me to start drafting mockups and I have a lot of other work to do.
I recommend reading at least the WinXP and Apple HIG guidelines (http://bit.ly/djCHb8).
Finally when in doubt copy Google, they have the an excellent web UX team.
Today we'll discuss the following:
- Summary of mailing list discussions on networking: VM network and
- Floating disks
- Snapshot behavior (and live snapshot if time allows)
Based on my recent experience with entity search, I have created a Wiki
page providing step-by-step instructions on introducing entity search
for a new entity in oVirt. It is available at following URL:
Please feel free to contribute to the same in order to correct any
discrepancies or enhance the information provided.
as the same entities as the ones used on the server are also sent to the client
(e.g. org.ovirt.engine.core.common.businessentities.VM), this entities will than
be serialized/deserialized using the GWT serialization. It means, this entities
should follow the restrictions given by the GWT serialization:
>From it I would like to point out this:
"Fields that are declared final are also not exchanged during RPCs, so they should generally be marked transient as well."
It means, that no fields which will be sent to client should be marked with the final keyword.