Posts Tagged ‘Mobile’

7
Nov
2014

Will cars become the new mobile?

by Mike Altendorf

FutureCar

It seems slightly crazy to be talking about ‘the new mobile’. It seems like mobile only recently became the new mobile and I can’t even remember what it was before that. Such is the speed of change in this digital world of ours that simply by proclaiming something ‘new’ makes it old. What I find particularly interesting at the moment though is that it seems it is more reinvention than invention. The ‘internet of things’ is in the process of breathing new life into a host of everyday objects. I heard today about a company that is developing a lock that will text you if it is being broken into; I have heard about belt buckles that will alert family members if elderly relatives go on an unexpected walkabout; shoes that analyse the way you run, even toilet paper holders than text you when they are about to run out (ok, maybe I made the last one up).

All of sudden every physical thing around us has an opportunity to become something else. The thought is actually overwhelming. Can we deal with that much information? Do we need it? At what point does it become too much? In a dot.com-esque way there is no doubt that there will be many missteps along the way but there is no doubt that the ‘internet of things’ is set to revolutionise our lives and there is one piece of everyday equipment which I think has the potential to become ‘the new wearable mobile’ and that is the car.

The idea of the car that is more than the car has been with us as long as the car has. In 1938 at the New York World Fair General Motors predicted that motorists would be able to simply type in a destination, sit back and relax (http://www.economist.com/news/business-and-finance/21618531-making- autonomous-vehicles-reality-coming-street-near-you). Those of a certain generation will have dreamt of having their own Kit that could not only talk to them but could save the day against any baddy out there (and there is always the Batmobile of course). Cars have always had huge potential and right now we are on the cusp of that potential being realised. As far as platforms go cars have far more to offer than the mobile phone. They don’t just tell you where to go, they can take you there. The computing power in the average sedan is already overtaking that of a smartphone. Sensors help us park, keep us from getting too close to other cars on the road, alert us to obstacles, sense and adapt to different weather conditions, open garage doors. We can call, email, surf the web, watch movies. Almost without us noticing cars have become a whole lot more than four wheels and an engine. 

The reality is however that we have barely scratched the surface of what is possible. With the exception of mobiles and computers, cars are the machines that the majority of us spend the most time engaging with and now we have the possibility of them communicating with their surroundings? This not only opens up the idea of the self-driving car but of a whole transport network that is communicating internally. Cars talking to each other, to traffic lights, to buildings: Cars that are monitoring you as you drive, evaluating your behaviour and adapting accordingly, communicating with people and places. Imagine a car that can not just call for help from an accident but automatically request an ambulance? Cars that can prepare your house for your arrival or come and pick you up when you have had more than half a pint? 

The thing is once we no longer need to concentrate on the road that frees up the time we spend travelling to do other things. Retailers need to consider whether a car will become the next device from which people will shop and how they can exploit tech to connect with it. Unlike the mobile it doesn’t need to be small enough for us to carry round – in fact it will be carrying us around. What would you do with a screen the size of a windscreen if you didn’t need to be able to see out of it all the time? 

All of this might seem a bit fantastical but when you consider how mobile has exploded in the last five years perhaps there is a chance that I will be taking delivery of my very own Kit sometime before my 60th birthday.

20
May
2013

Something about the Quirky World of Mobile Web Apps

by Haro Lee

On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.

 

scr-300-a

(There was a time mobile phones were simpler… or not…)

 

Libraries

To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and – significantly – doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.

 

How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned…

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.

 

Preloading

The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.

 

Sounds

A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.

 

Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.

 

App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated – to enable their easy reuse – with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.

 

Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements – a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.

 

Device quirks – iOS[I] vs Android[A] vs Blackberry Z10[B]

- on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

- in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

- overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

- shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

- <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

- ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

- ‘orientationchange’ event

[older A] not supported

 

co-written by Stephen Fulljames

 

7
Mar
2013

Device Independent Web – All For One, One For All

by Haro Lee

all-for-one-one-for-all
“All For One, One For All!”

 

What Happened…

A few days ago, I got an email with a url to an article on a website.
I clicked it without giving it much thought and the page opened on my web browser and for a moment I was puzzled as it looked quite not what I expected.

The font size was unnecessarily big, the paragraphs filled the entire width of the window, images were stretched, and I scrolled down and on the bottom of the pages there were several huge buttons filling all the available width.

At first I thought ‘what a badly designed website’ and then realised something was not right (other than it looked bad…).

I checked the url and it started with “mobile”.

Yes, it was the mobile version of the webpage.

I removed the “mobile” bit and it reopened the normal desktop version of the webpage now with a lot more comfortable look.

I figured out what happened there. The colleague was looking the webpage on his mobile phone and shared it by sending the url.

I’m sure many of you have the same experience.

 

Why…

I don’t want to start yet another debate what should a mobile internet be like or even the point of the existence of mobile internet (such as “There is no mobile internet” debates). There are plenty of other people talking about it with probably more knowledge than I have.

This post is not to argue or teach others what to do but just to talk about a little detail seems to be forgotten sometimes.

I appreciate the extra effort the people pour in to make their website look better on mobile devices or smaller screens.
Most of the times, it really helps my browsing experience.

But sometimes they seem to forget how advanced the mobile and web technology is becoming.

One example is Chrome browser on all the different devices.
As far as you are logged in, your browsing history and bookmarks are shared between devices. It knows what were the webpages you were looking on your phone so you can open them again on your desktop and vice versa.

It’s not just the browsers.

There are many many chances that you send an email with a link to somebody or even to yourself while browsing on your mobile phone and the recipients may open it on their desktop exactly like my experience above.  

That brings forward the importance of being versatile between devices.

In many cases if you open a webpage saved or sent from desktop on your mobile web browser, it correctly shows the mobile version of the page.

What it seems to be often forgotten is the opposite case.

Even a big company like BBC (http://m.bbc.co.uk) has forgotten it.

Maybe it’s like that so the developers can check the mobile version of website easily on their developing process, or just a simple memory loss, or hasn’t been considered at all, I am not sure.

 

A Little Thought…

One way to fix this quickly is just not to forget to check what device the webpage is opened on even on the mobile version of the website.

However, if you can afford to re-make the website, probably one of the most manageable ways of ensuring cross device experience will be using responsive web design. This may bring another good old everyone’s favourite debate of what and how responsive design should work but that is another story.

May your tool be Twitter Bootstrap (http://twitter.github.com/bootstrap/), Skeleton (http://www.getskeleton.com/), or HTML KickStart (http://www.99lime.com/elements/) or whatever you choose to work with for an easier start, or even your own creation.

Responsive web design lifts at least the burden of managing two or more different versions of the same page or template for different devices and it comes with an extra peace of mind that you don’t have to worry about the different devices and screens available on the wild all the time.

Another side effect of responsive design I like is that it makes the user experience less cluttered by forcing the designers and developers to think more about what and how to show and not, of course that’s if they are bothered to be bothered…

20
Jul
2012

New Birdsong Push Notification Service and v1.8

by Jon Sharratt

Just a quick post before the weekend to formally let you all know that myself and Joe today have released the new Birdsong push notification service.

Push Notification Service

We have released our shiny new service to Windows Azure today (a release on Friday…. naughty).  It has been a low risk release as the notification and live tile functionality as you all know hasn’t been working for a while.

With this in mind we wanted to get it right and have spent the past few weeks concentrating on implementing site streams from the twitter API to ensure we can provide you with almost instant notifications and live tile updates (phone connectivity depending).  I hope you all enjoy the new and improved service.  Development and testing has been an enjoyable challenge for myself, Joe and our test lead Samera.

NOTE: You will need to resave your notification settings for each account in your current Birdsong version (latest is v1.7) to take advantage of the new service.

NOTE: If you enable notifications in your current application favorited tweets and retweets will come through.  When version 1.8 is released these options will be configurable.

Birdsong v1.8 (Coming soon)

In regards to the next version of the Birdsong client we will be enhancing features for notifications to allow you to enable or disable toast notifications for favorites and retweets when they occur.

The final feature we have also added gives you the opportunity to turn on live in-app updates.  This feature will automatically refresh your timelines when you are mentioned or a direct message is sent to you.

As for the technologies we used and how the push notification was redesigned.  I shall leave that for another post…..

Have a great weekend, oh and don’t forget to set your do not disturb settings ;o)

27
Jun
2012

Functions to consider for Mobile testing

by Samera Butt

Having a mobile version of an application has now become a must. With mobile devices ranging from different OS platforms and tabletdevices – as testers, we have a lot on our plate!!

However, there are key points that we must consider whilst drafting out test plans and scripts for any mobile device. In this blog I attempt to cover some of the key points along with functional testing we should consider for mobile testing…

User Interface

Unlike our desktops, mobile devices come with various interfaces, from small screens that can be re-orientated when the device is physically rotated, touchscreen only devices to those which allow a combination of touchscreen and hard keypads, soft keypad only and not forgetting the various navigation methods such as hard keys and trackballs.

Being familiar with the device you are/will be testing on is important, if you are not, ensure you have a play around with it before testing. Check for the following:

  • Check for overall colour scheme/themes of the device. For example, Windows phone allow you to change the accent colour and background colours.
  • Style and colour of icons
  • Progress indicators when pages are loaded
  • Menu’s – how they are invoked and typical items they contain
  • Overall responsiveness of the application on the device

Screen Orientation/resolution: Applications should be tested in portrait and landscape view. Rotating the device fast, and checking to see the application’s response and errors

Touchscreens: Things to consider when testing touch screens are:

  • Multi-touch such as : pinch to zoom and single touch.
  • Long touch and short touch. For example, on some phones, pressing and holding an item will bring up a context menu, or a secondary function of a button.

Button Size & Position: Buttons and icons should be large enough to be seen clearly and be clickable by a fingertip.

Workflow: Use of radio buttons and checkboxes to minimize the amount of typing required, as this can be time consuming.

External Factors

Factors such as interaction with other devices and interruptions from the devices own functions such as incoming phone calls should be considered.

Factors to consider are:

  • Loss of Network Connections
  • Memory Card usage
  • 3G Network, 4G network, 2G network
  • No SIM card in the device
  • In airplane mode
  • Test intermittent network scenarios that a user might encounter in the real world such as:
    • Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
    • Ride in a lift or on a train where the network connection may go up and down
    • No network connection available at all

Device Options such as Screen Timeout/Auto on/off: Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.

Screen orientation: You may be able to enable/disable automatic orientation switches when the device is rotated. Does your application apply the setting set on the device?

Font: Does choosing a different font family, size, or style affect the appearance and usability of your application?

Connections: Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Phone devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your applications behaviour?

Emulator Use

Can be a great way to achieve testing coverage across multiple devices, but it is not safe to assume that just because your application works on an emulator, it will work on the actual device itself. When using Emulators, it is important to consider the following points:

  • Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
  • Some activities don’t work at all on emulators, like streaming video on a Blackberry emulator.
  • Due to lower device power and memory, the application could exhibit slower performance overall when run on an actual device (versus in an emulator on your powerful desktop computer).
  • If the emulator and actual device have different resolutions, your screens may not display as you expect.

Stress Testing

Mobile device applications have much less memory and power available than PC’s

Security Testing

This applies to applications which require sensitive data storage such as banking applications, and how the application behaves under various device permission schemes.

Mobile devices will no doubt continue to grow, and as testers we will need to keep up to date with the latest gadgets out there to keep on top of the latest changes in OS and functions belonging to a gadget. No doubt the device functions discussed in this blog will continue to grow.