Linked by Hadrien Grasland on Tue 11th Jan 2011 13:40 UTC
Thread beginning with comment 456989
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
More News »
Sponsored Links



Member since:
2010-01-21
I can also see this kind of priority-based UI management being beneficial to desktop users. It'd make tiling WMs and non-maximized windows more useful on screens smaller than about 1.5 times whatever the app was designed on.
I have two 1280x1024 LCDs, but I can't tile all of my apps beyond "maximized, one per monitor" because the functions I use in some of the ones I use frequently are laid out to assume at least 800 pixels of screen width, almost none are OK with 480px, and I'd probably waste as much time as I'd save if I didn't spend a week fine-tuning the tiling algorithm with a table mapping apps to minimum dimensions actually producing usable UIs.
It's why I'm working so hard to make the desktop and mobile versions of my current web app project comfortable while differing by little more than "mouse vs. finger" for the button sizing guidelines. (Among other things, I've got the current testing layout down to Chrome with scrollbars at 800x600 I'm now working on a linearization scheme to bring the minimum usable width down further)