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..
Related
I am developing a website that will be used by two sets of people. One set will have 22 inch monitors, then other set have varying sizing but some are antique and some are pretty small.
My question is, is testing on one monitor under different resolutions (e.g. using Screenfly) the same as testing on several monitors of different sizes? This question created some debate with my colleagues, but ultimately we don't really know.
There are few things to consider.
Device what is viewed on, a Mobile device, PC, etc. Mobile devices treat websites differently. Even if the resolution of the screen is to say 720p, browsers tend to display them as a 340px wide screen in portrait view.
Also besides screen size, you have to consider the resolution of the screen, You can have a 14-inch screen with a resolution of 1920x1080, or you could have a 40-inch screen with the same resolution.
So with all of these in mind, it becomes quite cumbersome to test for specific screen sizes. Programs like Screenfly and many others do a good job. But can hide some bugs and glitches. As they cannot copy the native support of the device, they mimic as well as they can. If your website is simple, it should do fine if you have followed responsive design practices. However if it JavaScript heavy website it could fail to display potential problems.
So in conclusion. No, Screenfly is not 100% guaranty there will be no bugs on the actual device. The best solution would be to test on actual devices of varying size.
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
AR browsers include those like wikitude, Layar etc that are available for Iphone and Android smartphones .
When you point your camera to a landmark they automatically overlay previously available information for a location over it (e.g. name of a restaurant over its door)
If the accuracy of GPS as states by some is ~ 10 m , how can this be done accurately ?
I mean if they track the location of your phone to display geographically accurate information , a difference of even 2-3 m can cause havoc.
you can check by yourself in the code of mixare, which is an augmented reality browser released under a free software license (GPLv3). The source code is available on github both for android and iPhone.
To answer your question: there are errors, mostly because of the compass readings (digital compasses are unreliable because they pick up every kind of noise). What helps is that you are usually looking to objects that are quite big (buildings etc.) hence the error is not THAT visible to the end user, but it's still there, trust me :)
HTH
Daniele
Disclosure: I am the project leader of mixare and main developer of the android version
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.
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.