Recently I have been working on a web site that has dedicated pages for mobile phone, so it seems a good time to go over a few tips and tricks that come in handy with mobile development. We will be looking at a quick comparison of the “desktop” website and comparing that to the “mobile” site, detecting mobile devices, mobile screen resolutions, handling tablets, testing your mobile site on a desktop browser,  handling screen orientation changes, and perhaps a few extra tips and tricks if we have time.

First a little on my philosophy for web development and how it relates to mobile. The design consideration you make are always a compromise and depend greatly on the project and your intended audience. So what is the right design method for one project could be entirely wrong for another. I have a few “rules of thumb” that I start with and then adjust based on the project. One of the first question to ask is this a site for the general public or an business app for “defined” users. If its for the general public then you don’t have much control over the devices that they will be using to visit your site. Next is what type of site is it, which I can generally boil down to this question, “Is it a brochure site, the next Amazon, or the next Quickbooks online?”.

A brochure site is mainly static content, it can be database driven but its mainly informational. You want the site to be viewed on any device, but it is fairly easy to create a responsive design for a brochure site.

If you are building the next Amazon, you want it to be used by all devices but the site is much more database driven. It is much harder to create a responsive design, but it can be done. So you have to make some design compromises. This is the type of site we are looking at today, so we will get into some detail in a moment.

The third type of site is Quickbooks online. I lump most of your business applications in this category. Notice the word application not site! Let’s be honest, no one is going to do tons of data entry on their cell phone. And you can also generally rule out Grama with her circa 1995 VGA monitor and IE6 as a user. So you can design for a higher resolution and do other things that might limit its use on mobile devices. What I tend to do in this case is a hybrid, with a mobile option that is much more limited than the “desktop” option, a few quick and easy entry screens that may be needed but more for information viewing than entry for the mobile version.

So back to the Amazon style site, which is what we are looking at today. We basically have 3 possible browser platforms, desktop, tablet, and phone. For this type of site, I generally develop for two, tablet and phone. Again it depends on the project, but generally if you develop your desktop app, for 1024×768 and use a few visual tricks so that it doesn’t look lost on larger screens then you have covered all tablets and desktops that might be using the site. That leaves you with mobile phones, some of which of higher resolutions now, but will make the site so small it will be unusable. So the target size I use for the mobile pages is 320×460. There is very few designs that you are going to be able to make responsive enough to work for all 3, and you will end up with a comprise that will make no one happy. Just take a look at Amazon or any of the other “big boys” that have development budgets larger than some country’s GNP. The generally have a mobile site that works completely different, and that is for a reason, your interface needs to take in consideration the platform. We will see a few things we did in this site for that.

One last quick word before we move on to the looking at the actual site, because I am sure the question will come up. What about native mobile apps? My general rule of thumb there is unless I need to take advantage of the hardware, dial phone, GPS, barcode scanner, etc. then I develop mobile web. If you go with a native mobile app, then you have at least 2, android and IOS, and you are dealing with their store ecosystems etc.

So finally let’s take a look at this site for today’s talk. The site is a hotel booking site, which has a considerable amount of private labeling ability built into to it but for today we are just look at the general design, in the future we might talk about the private label code.

So first lets take a look at a few screen shots from the desktop app.

This is the first page of the site in desktop mode, on a fairly large resolution. However the site itself is only taking up 1024×768. I am using a few tricks to create an optical illusion that the site is using more space than it really is.  First the browser background and the page background are the same color and bleed together, which keeps you from having the square box in the middle of the screen look that many sites (and the standard Webdev templates) have. Next notice that the header “gray bar” which is slightly darker than the rest of the page, stretch the entire browser width, although again the controls are actually centered in the same 1024 area. This again tricks the eye into believe the site is using more real estate than it actually is.

Now a few specific site features that we will discuss, notice the calendar interface that allows selecting the arriving and departing days via clicks, as well as the entry controls for entering dates if desired. We will see a completely different approach on the mobile site.

Also notice that the screen is basically split in half, with a left side and a right side. We did this early on, with an eye toward what would be the mobile site. Each half, will be a separate page on the mobile site. Which means the mobile site will have more pages, but that will allow us to present the info in a concise format that is more pleasant and not overwhelming on mobile.

There is also a navbar at the top of the site that shows what step we are on, and allows the user to jump back to a previous step.

The desktop site also uses popups to display detail information, such as clicking on the icon next to the room description. For give the ugly formatting, my test data is not in very good shape right now.

Now lets take a look at the mobile site.

The first thing you likely notice is the complete different color. We are going with a basic two tone site with Black background and white text, and no borders or graphics. This seems to give the site more of a “native feel”.

Next notice that the calendar is gone. We decide that the calendar interface would use to much real estate and not be conductive to the mobile interface. But we also didn’t want someone to have to type in dates. So since most folks are booking rooms for the next few days we give them “short cut” buttons for the next 5 days, and then an other dates button, which take you to an “alternate” first screen

Notice even on this screen, the date isn’t a standard entry control, instead it is a combo with Month and Year, and a second combo with the day. This seems to be an easier and quicker method of entering dates on a phone. I try to avoid anything that is going to cause the onscreen popup keyboard of the mobile interface to be activated, when it does it takes up half the screen which hides your interface and often makes things confusing. Dates are especially cumbersome to key in. In this instance I am limiting them to booking a max of one year in advance, so the two combos work well, I have a few other “custom” date controls that I use with mobile develop for other interfaces as well.

Also notice that the nights, adults and children, instead of entry controls, its a static and a plus and minus button. Again this avoids the popup keyboard, and the plus and minus keys are much easier for my fat fingers to press on a mobile device.

If we click on Find a Room, we see the something very similar to the right hand side of the first page of the desktop page. As discussed with the mobile version, each half of the desktop site becomes a separate page.

 

Uncle Pete’s Corner is webinar series on all things WX, to watch the watch the Uncle Pete’s corner webinar that is the companion to this article, and many other WX related webinars go to the WinDev US YouTube Channel and be sure to also join the WxLive – US Communityon Google+ to get notices about upcoming webinars. On the Google+ community you will find a active group developers discussing all things WX.

 

 

[suffusion-the-author display=’author’]

[suffusion-the-author display=’description’]

• WEBDEV
• WX