I am developing a website exclusively for mobile browsers.
What guidelines should I follow to optimize the site for mobile development?
My main concerns:
Most mobile devices have propriety browsers. How can the app be tested on those different browsers (testing on an actual device is not possible due to security restrictions)?
How to optimize the site for different screen sizes?
How to make the app touch friendly?
How to detect orientation of devices (in devices that come with an accelerometer)?
How to check that the device is not a desktop/laptop?
Things that I have used when designing mobile websites.
Find out the range of devices that you are planning to support. Some questions that you can ask are
Are u going to support only smartphones
What platforms are u planning to support ( iPhone, Android, Symbian ? )
A lot of you questions can be answered by the kind of Analytics that you are able to gather. If you have very less statistics then you can follow this strategy to start with.
Separate out the target range of devices into
simple ( basic phones with minimum browsing capabilities. ) - Design a very simple plain vanilla site for them.
medium ( older generation smartphones with browsers with poor javascript support ) - Design a site that has slightly better features.
Highend smartphones ( iPhone, Android, WebOS ) - Provide jazzy features that these phones support.
Use a device detection library like WURFL / .Mobi for device detection and WALL for dynamic rendering of content.
You can use .Mobi to detect an HTML5 compliant mobile browser. That way, you can take advantage of HTML5 capabilities in the devices that support it.
For testing you can follow this approach
test on browsers - Firefox / Safari / Opera have plugins to alter USER_AGENT and can simulate mobile testing.
Test on simulators - All the device platforms provide free to download emulators
If needed try device emulation products like device anywhere / perfecto.
I hope I was able to clarify atleast some of you questions. :)
The definitive guide has to be the W3C Mobile Web Best Practices: http://www.w3.org/TR/mobile-bp/ Don't let the length of it put you off - I find it much easier to read than other W3C specs. The key section is the Best Practice Statements, divided into bite-size chunks, often with an example. There's also a recent and extensive mobile web optimization guide here: http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/ (disclaimer: I work for Opera)
Q1 Most mobile devices have propriety browsers. How can the app be tested on those different browsers (testing on an actual device is not possible due to security restrictions)?
The answer depends on how many devices you want to test and support.
iPhone: device and simulator are available.
Android: devices and emulator are available
Other mobile phones?
check http://www.deviceanywhere.com
Of course, you need to pay service fee. But i think its reasonable.
Q2 How to optimize the site for different screen sizes?
iphone4
WVGA854
WVGA800
VGA
HVGA
QVGA
QCIF+
Making contents for all different size is difficult. So have to make a choice about screen size and supported models.
Q3 How to make the app touch friendly?
It is your design issue.
Q4 How to detect orientation of devices (in devices that come with an accelerometer)?
Android and iOS has special message about such event. You have to follow such message.
Of course, you need both landscape and portlait layout.
Q5 How to check that the device is not a desktop/laptop?
You can use User-Agent header or IP address. But IP address is not good method.
Related
I'm new to Roku development (in R&D phase actually). I read that we can't test Roku app on simulator and need real device. If we develop an application, how will we test it?
I checked Roku developer site and different links on internet, but could not find anything that answers my questions
As per my info, Roku sells 5 devices so:
Can we do one app that supports all 5 devices?
Do we need assets in multiple resolutions?
Do I need to buy all devices?
Can we do one app that supports all 5 devices?
Yes. Roku is trying hard to keep their platform coherent, though there are performance issues between the OpenGL and non-OpenGL devices. The "legacy" models (<2222) are no more supported, the firmware is kept current for the others.
Do we need assets in multiple resolutions?
Theoretically yes, practically - not really. You can make-do with assets in only one resolution, if you RTFM and pre-plan carefully. You'll need 3 sizes of app icon, no sweat. For the real UI though, you can either do HD (720) or FHD (1080) and leave it scale accordingly - the thing is TV is very forgiving to scaling graphics because of 10ft watching distance (60" 1080p screen is "Retina" beyond 8ft). Can largely snub SD.
Do I need to buy all devices?
No. And there are much more than 5 devices that are in use - see https://forums.roku.com/viewtopic.php?f=34&t=86471&start=15#p536994 for some statistics (RokuCo does not publish statistics, so that's about the best info available). If you buy only 2 devices, i'll say get
a #42xx (Roku 3 or current Roku 2) as reference model with OpenGL
a #27xx (Roku 1 or SE) or #5xxx RokuTV as reference for "slower", non-OGLES
As 3rd model i'll say the "new HDMI stick" #3600. You can get that one as the only device, its performance is somewhere between (1) and (2) above... but i don't think developing with only 1 device is a good idea.
One thing you may not have noticed is that there are also these "Roku TV" things under Hisense/TCL/Sharp/Insignia brands, models #5xxx. These are proper TVs with proper Roku smarts - meaning can run your Roku app. And one can be had for as little as... (skimming BestBuy web) $130-150 for 24-32" screen.
And i haven't even mentioned the 4k/HDR craze here, nor the new 37xx/46xx models that will be out for the holiday season (i only expect minor, evolutionary changes there).
Disclosure: I am a Roku employee.
That's correct, you'll need an actual Roku device to test your application. You can buy them used on eBay for very cheap ($20-35), or you can buy a brand new unit from our website for $50. The latest Roku Streaming Stick (Model #3600X) is my personal favorite option, and a great value.
You don't need to buy all devices, although we do recommend having many models so that you can QA test across devices. However, one popular development approach is to build your channel on a lower-end model, which theoretically will assure it works on higher-end models as well. This will also mean you have to spend less on your purchase.
Download our Precertification Checklist and open the third sheet, which includes a list of all our model numbers and corresponding code names. I'd recommend building on a "Giga" or a "Paolo."
Think of this cost as an R&D expense. Plus you'll get to enjoy the device on your free time as well!
As for your other questions:
Yes, you will only build one app that will work on all different devices. We do recommend taking the time to make sure your app is optimized across all devices, including older devices with less processing power. Our Performance Guide is a great starting point for this.
The other option is to check if the first number of the device model is less than “3” (which indicates it's a lower-end device) and add conditionals off that, such as removing animations.
You can find two examples of this on our RokuDev GitHub page:
Hero-Grid-Channel —> Components —> LoadingIndicator —> LoadingIndicator.brs —> Line 244
Multi-Live-Channel —> Source —> Main.brs —> Line 21
Yes, you do need different assets based on resolutions. Take a look at this document: https://github.com/rokudev/docs/blob/master/design/channel-artwork.md
Can Somebody suggest me whether it is effective to Test all as many mobile device as possible to ensure a website compatibility.
As per my view, it is good for some extent to test various version of a Browser to check the Page view and compatibility rather testing many mobile or tablet devices.
Please share your thoughts.
Your correct to some extend.When testing a mobile web site we need to be concerned about following
Browser compatibility
Page rendering in different screen resolutions/sizes
From above, we should pay more attention to Browser compatibility. And your correct on putting more weight on same.
By testing on many devices we can cover the screen resolution/form factor support.However, you should be able to create a good set of target test devices(Around 10)to cover the most used devices in the market.
For most used Android device types based on screen size, you can refer Android Dashboard for latest data
https://developer.android.com/about/dashboards/index.html
My suggestion based on current data, is to focus on following combination
Small Size - ldpi Density
Normal, Large, X Large - mdpi density
Normal Size - hdpi density
Normal Size - xhdpi & xxhdpi density
So for Android you can manage with around 7 devices for the initial round of testing based on current status
For iOS you could check the latest iPad & iPhone cause the platform has very few different screen sizes & adoption of the latest OS and device is better in iOS
Reference
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#ipad-usage
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#iphones-usage
Based on my experience with less than 10 devices you can have significant coverage on form factor support for mobile web testing.
Hope this is helpful..
I today had basic question in my mind ,what is the difference between
testing functionality in browser and same in mobile. say testing
m.gmail.com in browser and same directly in mobile using selenium.Is
there any difference other than the fitting into screen etc.
If you have a different server to handle mobile requests, you might have different implementation of the features, thus, you need to test both platforms.
The content might also be delivered according to the mobile browser used (Safari on the iPhone is much more feature-rich than the default N95 browser, for example).
Let’s look at some of the major differences.
Limited Real Estate
The most obvious difference is screen size. Responsive design is relatively easy to code for desktop and laptop browsers – most of which come with predefined ratios anyway.
By contrast, mobile devices are much smaller. Aligning images and text becomes a real challenge – especially when you factor in features like portrait orientation (i.e. the ability to rotate a mobile device and have the image flip accordingly).
Worse still, there is so much more variation – even when dealing with the same manufacturer.
For example, the iPhone 5 has a 4” display, whereas the iPhone 6 is 4.7” on the diagonal. When you add in the iPhone 6 Plus (5.5”), iPad Mini (7.9”), and iPad standard (9.7”), it becomes harder and harder to code and test mobile applications that look “good” on all screens.
Storage and RAM
Screens are not the only spatial constraint mobile software testers face. You also must factor in the limited storage and processing power of today’s mobile devices. Even high capacity phones can quickly fill up as users download apps and multimedia.
In the browser world, such constraints are moot. Desktop storage is essentially unlimited (measured in terabytes). And cloud-based storage is easy to increase, even if this requires charging higher prices to end-users.
Internet Access
With the exception of a few off-line browser applications (e.g. Gmail), Web-based software always requires an Internet connection.
Mobile apps may or may not need online access (although those that don’t often take up more space – see point #2 above). When Internet is needed, however, mobile software testers must factor in 3G and 4G – in addition to normal Wi-Fi.
In a nutshell Fast Dormancy allows the RRC state machine to go to IDLE(CELL_PCH) from CELL_DCH without waiting for the timer to expire. Is there any OS (Android, Windows Phone, iOS etc) which exposes APIs using which we can invoke fast dormancy on 3G devices? Any pointers appreciated.
EDIT: Does any OS expose API's to
switch off 3G radio or switch radio
states(DCH,FACH,IDLE etc.)
I'm not sure if I understood your question correctly (I'm not familiar with the actual 3G-technology), but at least BlackBerry API (since 4.2.1) does have the following method:
Requests that the radios belonging to
the provided Wireless Access Families
be powered off.
http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/Radio.html#deactivateWAFs(int)
Constants used with the above:
http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/RadioInfo.html#WAF_3GPP
Not sure if this is what you actually meant.
It seems that Blackberry also expose fast dormancy since API 4.0.0
http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/io/IOProperties.html#CDMA_SET_FAST_DORMANCY_FLAG
and
http://www.blackberry.com/developers/docs/4.0.2api/net/rim/device/api/io/IOProperties.html
The OFono stack used by MeeGo seems to have Fast Dormancy settings (and radio toggling) in the radio settings api, but I can't really see at which level those would be available to users. The API doc is in their git repo:
http://meego.gitorious.org/meego-cellular/ofono/blobs/5639c653979e324e0b3a195ec3fab07fc2bd3a05/doc/radio-settings-api.txt
I've read NCFD has been blamed for spotty 3G performance on iOS devices in some cases, so I'm not sure programmatically playing with at an application level is such a good idea, especially since you'd be making assumptions about the entire platform's network stack requirements.
My Google Fu is failing me today...
I want to expand the number browsers I support for my application. The amount of time it takes to test my existing functionality and on multiple browsers has become a limiting factor for expansion.
Is there a more pragmatic what to test layout and functionality across the various mobile and traditional web browsers?
Welcome to the world of development :)
IOW, no - you need to test each release for compatibility across all the devices that you want to support.