Motorola's Rumored Android Phone Focuses on Screen Size 134
nottheusualsuspect excerpts from this speculation-laden report at Brighthand that "Motorola is reportedly working on a device that will have one of the largest displays of any smartphone. Code-named the Shadow, it will sport a 4.3-inch WVGA+ touchscreen, Google's Android OS, and a range of other high-end features. When it comes to screen size, the Shadow will be equaled only by the Windows Mobile-based HTC HD2. The closest Android-powered model will be the Sony Ericsson Xperia X10, which will sport a 4.0-inch display. Most other models, like the Motorola Droid and Google Nexus One, have 3.7-inch screens. The display on this upcoming Motorola smartphone will allegedly have a resolution of 850 by 484 pixels."
So... (Score:5, Insightful)
This is rumor article about a rumored mobile device. This fascinates me and I'd love to know more. While I'm waiting I'll page through my Star magazine to see about Lindsey Lohan's latest escapades...
GOOG employee rumored to take a shit (Score:2, Insightful)
Seventeen other employees post about it on Slashdot.
Enough, already.
Re:Wow, so yet another screen size (Score:1, Insightful)
Sounds like a formula for long term retardation of progress. Having to stick within rigid standards makes it hard to innovate the device itself.
But this is Apple... where vendor lockin is a good thing from the same masses who cry about it when it's Microsoft.
Re:Wow, so yet another screen size (Score:5, Insightful)
perhaps people should start using units that do not rely on pixels to display their app? how about em?
That's no phone... (Score:3, Insightful)
Just what we need (Score:0, Insightful)
Re:WVGA+? WTF? (Score:3, Insightful)
Blame marketing.
Re:Basic Requirement (Score:4, Insightful)
And that's great, for you.
Personally, after trying out an iPod Touch for a few days (even in landscape mode) I just can't type worth felgercarb on it. Audible feedback is just, well, annoying to me. And for some bizarre and unexplained reason, annoying to those around me as well. Can't say why. "tick. tick. tick-tick-tick. tick-tick-tick-tick. tick-whoosh-tick. tick."
I can kludge along at a decent clip on my trusty old BlackBerry Curve, though, and could since the first day I got it. Nowhere near as fast as I can type on a desktop, but the feel of the actual physical buttons and the tactile feeling of pushing a button are huge advantages to me. I have to put a lot of text into my Blackberry, and I can't imagine NOT using a hardware keyboard.
Isn't it great that both companies make devices? ;)
Re:Wow, so yet another screen size (Score:4, Insightful)
WTF? Have you ever heard of dynamic layouting?
Yes, I can write one UI that scales from 128x128 to 1920*1080 without compromises. And so should you.
Re:Wow, so yet another screen size (Score:3, Insightful)
I've seen that sort of thing on websites. It's easy - just make sure you only use the left 22% of the screen, and leave the rest blank. Or centre the 22% of content. Whatever.
Re:Wow, so yet another screen size (Score:2, Insightful)
Actually, I'm pretty sure the scalable UI is going to involve at least some effort above a fixed layout, which is exactly a compromise.
Screen size is not irrelevant to UI design (Score:3, Insightful)
The physical size of the screen is irrelevant.
That is totally not the case. In mobile design you are working around very tight constraints around how many pixels wide a target like a button can be, because a finger can only hit a physical target so small (on the iPhone, it's 35 pixels although you can fudge downward a bit).
So when the physical screen size gets larger, that means you COULD design buttons smaller in pixel resolution to keep the same target size but allow more data to show. Otherwise your interface will end up looking goofy large on such a device - that might be OK, but if you are trying to make a really good application it's silly to ignore things like that. I mean, if no-one designs software to take advantage of this larger screen than what was the point of it all?
Hopefully the Android API has some way to get at PPI data in addition to screen resolution so the designer can design a flexible layout that allows for buttons and data to expand or contract as needed. I know the Android API very generally but not well enough to know if it has that.
Re:Wow, so yet another screen size (Score:3, Insightful)
It's not that it's hard, but it's impractical to test. Ever test high-DPI on Windows? And see how badly apps break? Because the screen sizes of most cellphones and PDAs is pretty standard, the high-res ones run in high DPI mode all the time so buttons don't get impossibly small to operate. Apps have to be coded to be DPI aware so they can scale their UI appropriately. This is easy on most apps using default widgets, but apps with custom widgets often have to be aware of resolution issues (games usually require this).
It's like websites that use Flash, and you move from a 1024x768 screen to a 1920x1200 screen. Suddenly that QVGA flash game you like suddenly becomes 10x harder to use because you can't see it well anymore. Or streaming video - that app that looked nice at HVGA (320x480) looks bad at VGA+ resolutions because the video was QVGA, and has borders and is now a quarter the size. You could scale, but if you're taxed for CPU time, it's even worse.
But mostly, it's high-DPI. And Windows apps already prove that most devs can't handle high DPI. Or flash apps.
In theory, the Apple devices stress the need to produce DPI-aware apps in the SDK, but it'll take a screen change to see it actually happen.
Some devices (old PalmOS, for starters) actually scaled apps on high-DPI mode if they weren't high-DPI aware. Looked ugly and pixellated, but worked for a large chunk of unaware apps...
Re:Wow, so yet another screen size (Score:3, Insightful)
Scalable UI has many more benefits than just working on screens of different sizes. It means, for example, that user can arbitrarily change font size and family, and the UI will adapt. It enables smooth seamless vector zoom in and out. It allows for easy localization (as lengths of UI strings can change a lot when localizing, so widget sizes need to adapt). And so on.
In short, yes, it's harder, but it's well worth the effort. If you look at modern desktop UI frameworks, they're all dynamic-layout-centric - Gtk, Qt, WPF, Swing etc. There's absolutely no reason why the same approach cannot be used on mobile devices. Let me define the UI as "two buttons, layed out horizontally, of equal size", and let the software of specific phone decide on the optimal size of buttons etc.