Most designers use 1024x768 as a baseline for website development. That allows them to use css grid systems like 960 & blueprint to easily outline content. Is there similar baseline resolution for designing for mobile phones?
The majority of users will be using iphone, android, and blackberry phones.
320 by 480 is the common screen resolution for new mobile devices.
iPhone Website Compatibility
Android Display Metrics
That being said if you want to support the majority of mobile devices, you may want to support multiple resolutions.
This website is super handy. An up-to-date database of various devices and their screen specs.
if you are using apache ApacheMobileFilter can help to determine the actual device screen size
You can
get the screen sizes for the devices you plan to support,
Create say, 2-3 versions of your site and detect useragent string and direct user to one of these sites.
With android, iphone and blackerry devices there is not large difference in a screen sizes. With a litle foresight and design you may be able to have all these handset work on one mobile website (for example it would be fair to say that the width would be 240 pixels or greater and design accordingly)
However if you plan to go further than there these platforms there is a world of hurt awaiting you, (J2ME, BREW, Symbian, WinMo and 120x160, 176x220 screen sizes etc)
I've found https://www.mydevice.io/#compare-devices to be the best site for determining this kind of thing. I was looking for the same and found this question via a Google Search, but most of the other websites mentioned above give you device pixels, not CSS/JS pixels, which is all that really matters in web development.
Sure, an iPhone 8 Plus may have 1080 actual pixels across its narrowest axis, but that is completely irrelevant to the topic at hand, considering that those pixels are much, much smaller than your HD TV for example. I wanted to measure the width of the display in relation to how a browser actually renders a mobile site and mydevice.io gives you that, as well as the physical dimensions. Win win! ;-)
Simply, no.
Lots of information here. http://www.quirksmode.org/mobile/
There are just too many devices with too many different screens to assume a common resolution. While it may be true that 320 x 480 can be found on many devices, it is by no means "common". You have to use flexible design principles and then use media queries or js detection to add a class to adjust your display to the proper dimensions. This is part of what makes mobile so difficult to wrangle right now.
yes there are 1024 x 960 x 800 x 768 x 640 x 480 x 360 for resposive web design sizes - better to go with percentages for avod this
I write games for mobile devices. In my code I position everything by percentage as it will always be the same, plus I also use a var to adjust how many pixels they have then set my resolution to suit You can do pretty much the same with css and a few different image size's in your resources.
Related
We are using images in my application but we have one issue with that i.e., the button was looking fine in 1280 x 800 resolution but in higher resolutions like 1920 x 1200 ,it was looking very small. Our requirement is to maintain consistency of images in all resolutions.
You need to use Multi Images see Understanding Images & Multi-Images in the developer guide. Notice that resolution doesn't matter, density matters as it is a better indicator for sizing elements.
What's the best way to write media queries for the Surface Pro 3 & 4? in both Landscape & Portrait views?
The best way would be not to write media queries for specific devices at all, but rather to identify logical places in your design to fold elements in or break them out accordingly, to account for devices of any width.
See this article for more info: Google Developers—How to Choose Breakpoints
In practice, the resolutions of those two devices you mentioned are 2160x1440 (Surface Pro 3) and 2736x1824 (Surface Pro 4). So, instead of setting those four breakpoints for your media queries, one logical approach would be to design for "greater than 2000px", "between 1200px and 2000px", and "under 1200px"—the first rule handling both devices you mentioned in landscape mode (also handling common desktop resolutions), the second rule handling both devices in portrait mode (and many other common portable devices), and the last rule handling devices of all sizes under 1200px.
This is just one way to tackle the problem, I'd recommend you research more carefully the common theories behind responsive design and breakpoint selection.
If I want to implement CMS for Mobile Devices, what kind of points should take into account?
For example, make page size smaller, use optimized (small) pictures. Any other ideas?
Also what kind of rules can be applied while converting web-pages that WERE designed for Desktop Browsers, to the ones that are easily displayed in Mobile Browsers.
I know that Mobile Devices widely vary in there capacity and property, but still trying list out some rules.
Also any other ideas, suggestions, questions and advices are welcome on this topic.
Thanks for your opinions and answers.
Short foreword, all the things I'm listing below are something the main product of the company I work for already does or has worked out a solution for, the whole goal of this answer is to give you pointers.
Identifying the phone
When dealing with mobile as a web context, it's absolutely imperative you identify the phone correctly. That should be the highest priority. Here's couple of issues with identifying phones and their features:
Do not use userAgent.contains("iPhone") detection scheme. There's already loads of web bots and other applications which contain iPhone in their user agent string and thus you'd identify them incorrectly.
Not all phones even send User-Agent headers. However some of those send UAProf URL:s which contain all the phone's features in RDF format. Unfortunately this introduces the next two problems:
Obviously you won't have access to every single device data out there and you're bound to use public data repositories such as WURFL. These databases are however incomplete, slightly lagging behind or don't contain data you'd like to have. They are your best bet for initial data set though.
UAProfs lie. Yes, they contain false information - lots of it! Partly this is because the manufacturers forget to update the XML:s and partly because the UAProf files are written during the development of the phone and as we know, features do change during development.
When relying on a feature, make sure you're not relying on a specific version of a specific phone. For example BlackBerry has a feature called Tile which is basically a really fancy bookmark but you can't just serve it to all the BlackBerry phones, you have to identify the operating system version of the actual phone to serve the right variation of the Tile. Same goes for touch screen, iPhone wasn't the first one with touch screen and most certainly isn't the only one either - also don't expect a situation where the device has only one form of input, for example Nokia N900 has a touch screen, physical keyboard and even stylus.
Creating the actual pages
Thankfully this is something people have agreed upon and when creating the pages, you're supposed to use XHTML-MP. But oh how one would wish things were this easy...
All phones have differing level of XHTML-MP/CSS support. As an example, if I remember correctly, some older BlackBerries don't support background-color for block elements. Or header tags. We've also seen incorrect ordering of span elements when there's several in a row. Oh and for some reason tables are really hard. Basically, you have to go low on markup/styling tricks.
You can't test the existence of the feature by using the feature itself. If you want to detect JavaScript support, you could think that adding a bit of JavaScript to the page for that purpose alone would work, right? Nope, that crashes a significant percent of mobile phones visiting your site. Sure, new phones don't crash but not everyone has bought their phones in the last 12 months. Also mobile specific JavaScript API:s differ per manufacturer, as yet another example there's currently at least three different API:s for JavaScript-based geolocation detection, none of them interoperable with the other ones.
Add all these on top of normal CMS features (security, content management and transformation, caching, modularity, visitor tracking and whatnot) and you should have some sort of picture of how everything affects everything and how you really should consider the cost of making your own.
In fact even though this is sort of against the general spirit of SO, I'd strongly suggest for you to get a readily made solution such as ours and use that instead for your site building needs. After all, our product has seven years worth of specialized development under its hood.
A couple that we used ...
A cms targeted for mobile devices should be able to detect the device type and detect (or have a database of) screen resolutions so that content, particularly images, can be scaled appropriately.
The rendering engine should also be able to determine if the device can handle HTML or WAP and switch markup languages appropriately.
Paging capability on the output as opposed to rendering very large pages (if content mages are large) is also helpful.
Clean integration with the corresponding web site CMS (so content doesn't need to be dual produced) is also helpful if tere is, in fact, a corresponding large form web site.
I'm trying to build a mobile application on a client-server model where clients are people's mobile devices and the server is a PC - all connecting over bluetooth.
I'm expecting the client to be very thin - just enough to establish communications, display some text, and relay user input.
What's the best framework to develop in? I want the maximum possible device compatibility (so for example not just series 60 capabale devices) as opposed to cool features - but the ability to scale easily to colour devices or ones with higher dispaly resolutions would be nice.
In the current mobile space, largest installed base + limited functionality = use JavaME. See http://java.sun.com and the the stackoverflow j2me and javame tags.
Easiest way might be to write MIDP application that uses Bluetooth API. That covers widest range of devices with least effort.
When desinging UI for mobile apps in general which resolution could be considered safe as a general rule of thumb. My interest lies specifically in web based apps. The iPhone has a pretty high resolution for a hand held, and the Nokia E Series seem to oriented differently. Is 240×320 still considered safe?
Not enough information...
You say you're targeting a "Mobile App" but the reality is that mobile could mean anything from a cell phone with 128x128 resolution to a MID with 800x600 resolution.
There is no "safe" resolution for such a wide range, and if you're truly targeting all of them you need to design a custom interface for each major resolution. Add some scaling factors in and you might be able to cut it down to 5-8 different interface designs.
Further, the UI means "User Interface" and includes a lot more than just the resolution - you can't count on a touchscreen, full keyboard, or even software keys.
You need to either better define your target, or explain your target here so we can better help you.
Keep in mind that there are millions of phone users that don't have PDA resolutions, and you can really only count on 128x128 or better to cover the majority of technically inclined cell phone users (those that know there's a web browser in their phone, nevermind those that use it).
But if you're prepared to accept these losses, go ahead and hit for 320x240 and 240x320. That will give you most current PDA phones and up (older blackberries and palm devices had smaller square orientations). Plan on spending time later supporting lower resolution devices and above all...
Do not tie your app to a particular resolution.
Make sure your app is flexible enough that you can deploy new UI's without changing internal application logic - in other words separate the presentation from the core logic. You will find this very useful later - the mobile world changes daily. Once you gauge how your app is being used you can, for instance, easily deploy an iPhone specific version that is pixel perfect (and prettier than an upscaled 320x240) in order to engage more users. Being able to do this in a few hours (because you don't have to change the internals) is going to put you miles ahead of the competition if someone else makes a swipe at your market.
-Adam
Right now I believe it would make sense for me to target about 2 resolutions and latter learn my customers best needs through feedback?
It's a chicken and egg problem.
Ideally before you develop the product you already know what your customers use/need.
Often not even the customers know what they need until they use something (and more often than not you find out what they don't need rather than what they need).
So in this case, yes, spend a little bit of time developing a prototype app that you can send out there to a few people and get feedback. They will have better feedback because they can try it out, and you will have a springboard to start from. The ability to quickly release UI updates without changing core logic will allow you test several interfaces quickly without a huge time investment.
Further, to customers you will seem really responsive to their needs, which will be a big benefit to people who's jobs depend on reaction time.
-Adam
You mentioned Web based apps. Any particular framework you have in mind?
In many cases, WALL seems to help to large extent.
Here's one Article, Adapting to User Devices Using Mobile Web Technology exploiting WALL.