Scott Lawrence wrote: > On Tue, 2009-12-15 at 15:25 -0500, Paul Mossman wrote: >> Hi all, >> >> I just merged a new sipXconfig Admin and User portal layout (and >> graphics) from branches/user_mdasilva_skin into main. (XX-7253, >> revision 17532.) >> >> These are major changes, > > Quite aside from the issue of getting the unit tests working, I'd like > to have a discussion on whether or not the proposed new UI is actually > an improvement or not before it is merged to main. > > I have looked at it running, and I find it to be a big step in the wrong > direction in a number of respects: > > * It has much more empty space, which it achieves by adding > gratuitous internal borders (the functional part of each page is > in a white floating round rectangle within a larger colored > background). > > * Most of the fonts are, by default, significantly smaller than > the ones in the existing interface - even very important text > like the top level menu titles are very small text. > > * It has wide fixed-width elements at the top, resulting in very > poor layout when the screen is narrowed (made smaller > horizontally). > > * Changing the font size in the browser (which I routinely do when > faced with very small font sizes on my laptop screen) caused > many bad layout effects - the text expands to outside the boxes > and other framing elements. > > * It uses graphical elements overlaid with link text for controls > - these are very poor from an accessibility point of view, and > often pose a problem when localized text is significantly > different length. > > I don't want this to be all negative - I did like the color scheme, and > the general 'softening' of the look was good (to the extent that it is > implemented without the problems above). I'm sure that a longer and > more detailed look would have found other positives. > > I'm very much supportive of spending time and effort to improve the look > of our UI - visual appeal is very very important, but so is good web UI > design. I'd like a design that makes better use of space (whoever is > doing the design should be regularly looking at it on a small laptop > screen, and changing window geometry frequently, because real users need > those things). It should also be compatible with existing sipXecs > skinning conventions; if that cannot be done, then I think the change > should be put off for a major [4.x->5.0] release so that community > members who've build their own skins have more time and warning to > participate and adapt. > > I also think that some time spent reviewing where various elements are > in the navigation structure so that they are grouped in a more intuitive > way would also be a good idea (I realize that was deliberately out of > scope for this effort), but I'm sure it's too late in the 4.2 cycle to > open that can of worms. > > >
In addition to what Scott said about how things look to the user (and I agree with all he is saying), let's not forget about how they look to developers (who will have to maintain the new skin). New skin is using HTML and CSS techniques/hacks that are not necessary (as in: you can get the same results without restoring to them). It may be acceptable when you are implementing a one off WEB page, not when you are planning to have a WEB application that is changed constantly. People adding new pages should not worry about the fact that the titles will overflow, button text will not fit into a hard coded image or that a menu will not look good if you add one more entry. Some of the things in the code that need to be fixed before this can get into mainline: - Styling elements should be in CSS not in HTML. Adding 'style' directly in HTML practically ensures that no-on can write an alternative skin. We have a few places where it's wrong in current skin but they are not nearly as common as the new one (grep to see what I mean). It would also allow for easier merging of the skin. - Rounded corners effects are implemented using fixed .png: although IE is somewhat behind the curve on that, one all other browsers support CSS properties that give you much nicer effects and also support scaling. It all degrades nicely in IE (and IE will catch up soon as it did with many other features). - Fixed width of buttons, dropdowns should be kept to minimum and expressed in em not in px (relative to the text size, not to the pixel size) - this is what's causing issues with non-standard fonts and huge accessibility problem with changing font size. This is also puts a burden on fitting the content into the button on page developer: it *will* slow down adding new features. - Fixed layout is absolutely not necessary (and please note this is a part of implementation, not part of the design - page looks the same until you start changing the browser window width). We have a lot of information to display, we should not ask users to scroll down to see it if they paid a lot of money for a nice big monitor - layout.css was always too long - it now grew from 700 to 1700 lines: this code needs to be carefully reviewed -- the C in CSS stands for _cascading_ - there is no need to enter all information for each and every element, specify base style on override it in this way people can change something only on one place (one example: specify font-family once for a 'body', overwrite only when needed) -- instead of specifying the same property over and over again declare a new class and apply multiple classes to the element - onmouseover, onmouse javascript to attach/detach CSS classes has no place in HTML - that's what CSS :hover is for - adding jquery just to have a custom drop-down box seems excessive: do we really want to spend time supporting this with each release from now on? Don't get me wrong/ I like jquery, I am on record advocating using it instead of GWT to implement user portal, but adding a new library has to be justified (also don't forget updating NOTICE file). - IE hacks should go into separate files - ie?-hacks.css (BTW: no need to add any new IE6 hacks - we stopped supporting it couple of releases ago) The division between layout.css and color.css that allowed people to play with colors without changing layout (and which kept layout.css short) is now lost - colors are specified in layout.css and in many cases they rely on images. sipXconfig always supported replacing sipX logo with your company logo without replacing the entire skin: it's not possible any more since .png's are not loaded through sipXconfig skin service. I didn't actually spend a lot of time using the skin. The things I mentioned here are related to the implementation not to the look and feel of the new skin. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
