One option is to design it with CSS – add a border here, a background there, and you’ll get something that looks a little bit like a button. Take advantage of some CSS3 features such as border-radius and maybe a gradient background and you can come up with something really nice.

But what happens on phones that don’t handle CSS3 (or CSS in general) that well? You’ll get a rubbish looking button, that’s what !!

Another option with CSS, is to create an image, and reference it with via a background CSS property. But you’ll have the same issue as above – some phones will display it ok, but some won’t.

So to try and help with this, we’ve added a new form item – Image submit. You’ve had image submit buttons in HTML for ages and now we’ve added this feature to both Canvas and Architect.

In Canvas, you simply create a new form item of type “Image Submit Button”, and assign it a graphic you’ve already uploaded. No relying on CSS and if a handset can’t handle it, we’ve got a fallback in place.

In Architect, create a <formItem> element, and specify a “graphic_src” element – the system will use this URL as the basis of the image. If you don’t want it to scale, set the graphic_scale to 0 – check out our formItem documentation for a more in depth analysis.

Let us know if this new feature helps you out and send through the URL of your site so we can take a look at your new submit buttons!

Rules to check if videos are supported, rules to check for active campaigns, rules to check for specific screen sizes.

Of course we have hundreds of others, but something missing from all of them was the ability to have customizable rules to specify your own test criteria.

Dynamic Rules

So what we’ve done is add dynamic rules to Canvas so you can actually define values for certain rules to meet.

For example, if you wanted to launch your site on BlackBerry phones running RIM OS version 4.6.0, you’d create a dynamic RIM OS rule and enter “4.6.0″ as the value.

We will be rolling this functionality into a load of other dynamic rules, Symbian OS, iPhone OS, Bango operator results plus many more – we’ll of course keep you updated with any new developments!

Alternatively, if you want to find out how rules work in WAPL and Wapple Architect, check out our help documentation over at http://wapl.info/coding-for-the-mobile-web-with-WAPL/chapter/Rules/

UPDATE

We have added even more functionality into this feature – the ability to have operators on rules, so you can test if a software version is above a certain value, or equal to something else.

It’s called the Video Link chunk – login in Canvas and add one to a page to see it in action!

If it’s a YouTube video you want to show, a thumbnail is generated automatically, but for other video sharing websites, you can specify the location for an accompanying picture.

If you have an iPhone, videos will display with a play button on, allowing you to play the video with the native controls on the phone. Anything else and you get forwarded to the URL – of course when other handsets add functionality in for video playback, we’ll update the chunk!

If you want to know how to add a Video Link chunk with Architect and WAPL – check out http://wapl.info/coding-for-the-mobile-web-with-WAPL/chapter/Video-Link/ for more info.

Inside of Canvas, the graphic chunk functionality used to rely on the fact that you’d uploaded a graphic before telling our mobile rendering engine what size you wanted to display it.

But what about if you didn’t want to upload a graphic – you might want to just reference another image on another site directly by its URL.

So we’ve made a small change to the graphic chunk and added a setting so you can use a URL as the graphic source. You get all of the same controls over the size and alt text, just you don’t need to upload it first – hopefully simplifying the whole process.

Get in touch if you’ve used this feature or let us know what you think and whether there are any more changes you’d like.

I’ve written a much more in-depth article over there about how we did it, but here’s a bite-sized version that you can cut out and put in your wallet:

1. Install the Wapple Architect Mobile Plugin
2. Grab a free dev key from http://wapple.net/register/plugins-signup.htm
3. Activate the plugin and enter your dev key in the Basic settings area
4. Upload a mobile logo
5. Tailor settings so that the mobile version matches the web
6. Style the mobile version so that you retain your brand identity

If you want to read the full article, you can check it out here.

And finally, here is a screenshot of the mobile and web site that shows you how good your mobile blog can look!

Overcoming the barriers of mobile web design and development – it’s the tagline of our blog and something that we strive towards each and every day.

We’ve given the development community some amazing tools that allow you to create some fantastic mobile sites and we’ve created plugins, components and classes that help you at every step.

But one thing every Wapple Architect application has in common, is that in order to use it, it must be done via SOAP.

Or should I say, used to have in common, because this week we’ve created and released a REST web service for every SOAP call you can make.

Using Wapple Architect with CURL

What this means as a developer is that you can choose whichever method you want to communicate with Wapple Architect. If you want to use SOAP, carry on doing what you’ve always done, but if you want to use REST, use it. And to show how easy that can be, here’s how you would check if a visitor to your site is mobile or not using PHP and CURL:

<?php
$headers = '';
foreach($_SERVER as $key => $val)
{
 $headers .= $key.':'.$val.'|';
}
$postfields = array(
 'devKey' => 'YOUR_DEV_KEY',
 'headers' => $headers
);
$c = curl_init();
curl_setopt($c, CURLOPT_URL, 'http://webservices.wapple.net/isMobileDevice.php');
curl_setopt($c, CURLOPT_POST, 1);
curl_setopt($c, CURLOPT_POSTFIELDS, $postfields);
curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($c);
curl_close($c);
if($result)
{
 // We're a mobile device! Generate some WAPL and use getMarkupFromWapl.php service!
} else
{
 // Not a mobile device - generate HTML and output to screen.
}
?>

Once you’ve established that your visitor is a mobile visitor, you can use the getMarkupFromUrl.php or getMarkupFromWapl.php services and amend your $postfields array to include the ‘url’ or ‘wapl’ keys respectively.

Architect with SOAP or REST

So if you’ve looked at using Wapple Architect before but for one reason or another couldn’t or wouldn’t install SOAP, you’ve now got another option that allows you to mobilize your site or app!

We’ve already integrated these new services into our Wapple Architect Mobile Plugin for WordPress so that if you don’t have SOAP installed on your server, you automatically fall back to using REST. And lets face it, if you’re on a shared host, getting SOAP installed is not a task to be taken lightly and can be tricky.

What do you think of these new REST services, does it mean you’ll use Wapple Architect? Do we need even more coverage of web services – XMLRPC for example? Get in touch and let us know!

There’s an ongoing debate on the subject of mobile web transcoding, so here’s our take.

Let’s be clear on our language here though. Transcoding videos for mobiles is essential and very good, but doing it to your web output is bad. Really bad.

A reliance on an automated process that takes HTML output and reformats it to mobile markup is a deluded one. Computers are really bad at recognising diverse visual patterns (that’s why we all use CAPTCHA to protect from bots) and you don’t get much more diverse than web design. If a transcoder has been taught your web layout, you’ll find yourself tied to that web design or face losing any learning invested in the system.

The core point however is that mobile users have different desires and demands to you normal web audience. They don’t want to search for information – they want it served to them. They want access to services that are typically mobile, not those that are more comfortably engaged in while sat in front of a 19inch monitor with time to spare.

The solution is to write mobile applications for mobile from the heart of your server outwards, sharing logic and data.

With this approach you can utilise all the logic, models and controllers (if you’re that way inclined) from your existing web services but present them using view layers that are ideally suited to mobile devices. You can omit features that are simply not made for mobile and include new ones that would mean nothing to a web audience but are essential to visitors on the move.

Wapple Architect allows you to output a single markup language for every mobile device. The process will automatically adapt your WAPL markup to each and every mobile device – but this isn’t transcoding – it’s taking the output, layout and data described in WAPL and returning the correct markup for any particular device.  Watch this video to understand more.

Wapple Architect beats automated transcoding

Don’t be fooled by the sirens singing the song of transcoding. They will bite you in the backside sooner or later. Transcoding is at best a quick fix but as an enterprise level approach to catching the mobile web wave it will ultimately disappoint your users, create an extra layer of work for you over and over and simply glosses over an issue rather than addressing it entirely.

Code, don’t transcode.

It seems to have attracted a lot of flames. Blimey! Time for Mobile Web Junkie to dive in…

Read the  article. It’s great.

If you’re trying to make money, dump your iPhone strategy

Then the comments but in case you feel too much pain before you get as far as my comment, here it is, just for you:

Wow, what a lot of hate in the comments. I really think that a lot of you need to read back what you’ve written and see if it’s truly in the spirit of constructive debate.

I would suggest that every single flame has been posted by iPhone owners. A trait I’ve noticed is that as soon as someone jumps onto the Apple train they feel they have a fight on their hands. I guess it’s a complex caused by Microsoft constantly trumping Apple in the OS battle.

Let’s all calm down a little. There really is no need for all this flaming.

I don’t like the iPhone but I do recognise that it has done wonders for educating the public that there’s more to mobiles than just voice and text. Finally we have a platform that can do so much more, but importantly it makes extra applications accessible and consumable.

My problem is that the worldwide market share that Apple has is actually a lot smaller than iPhone fans would have you believe. Given the amount of absolute trash that is available on the App Store I find it difficult to believe that enough people make money out of selling apps to maintain a sustainable environment.

This problem is not just Apple’s. I recently switched from Nokia to Android and I am inundated with rubbish and duplicate applications in the Marketplace and I am overwhelmed to the point that I cannot discern good from bad. It has become painful to find applications because of the distinct lack of editorial to filter the stuff that matters from that which doesn’t.

I am a mobile web expert – developing and delivering services for mobile web for the last 7 years at Wapple. I believe in the broadest possible publishing models and I believe in open markets not manufacturer-owned distribution channels.

The mobile web unifies all operating systems. Mobile web is the platform that we should all be publishing for as it is unrestricted and platform independent (provided you use the correct tools to overcome device variations).

A colleague of mine was a complete Apple head. He spent a lot of money on the App Store – then he had his phone stolen during a night out. Disgusted with O2′s refusal to honour the insurance policy he had paid for he bought himself a new Nokia, swearing never to return to iPhone again.

He lost all his apps. Those that he had paid for.

More worryingly for everyone in this forum, he was lost as a customer to those businesses relying on his ongoing custom through the App Store.

Though all the services that he engaged with through his mobile web browser were maintained as he moved to a new operating system.

Now the theft of a phone is an extreme example, although we can all relate I’m sure. But let’s look at our own histories. I am a Windows PC user and have been for 16 years. Sure I’ve used other operating systems fleetingly but I have worked with the same software and service vendors for years.

But when it comes to phones, I have used many different models from different manufacturers. Every 18 months for the last 10 years I have changed models and manufacturers.

I find it hard to believe that anyone will be an iPhone user for life. Right now iPhone is the ‘big thing’. All the decision makers have them (what about all the customers, though?). But it will not be the big thing forever.

Users will migrate. You will migrate. Then all the development and marketing you have put into attracting a small slice of the entire mobile audience will be for nothing.

Personally, I’ll keep developing for mobile web. It’s not a direct competitor to mobile apps anyway, but I do know that what I make will move with me, my customers and the market through all its twists, turns and trends.

http://www.useit.com/alertbox/mobile-usability.html

We’ve been saying this for years and I wonder what took Jakob so long to discover the mobile web anyway? Maybe he was on a really long phone contract and only just got an upgrade. Or maybe his handset was so cluttered he only just found the browser.

Either way, he’s on board now and whether you subscribe to his somewhat draconian dismissal of everything pretty over everything useable you will certainly recognise the importance of such an influential character entering the affray.

Now, I’m a little dubious about the research itself, but mainly that’s because I already knew that getting a test subject to access a full website on a mobile browser is UI suicide. I’m not disregarding the findings at all, because I agree with the conclusions. I just feel that the approach could have been to  look at sites already designed with mobile in mind might have helped us advance the cause rather than assist the stragglers.

To summarize the problems in his research findings: ‘Websites don’t work on mobile because they are designed for a big screen and mouse controlled GUI.’

The solution, of course, is to actually make dynamic and optimizing services for mobile.

As a developer or designer, once you begin on this path, usability common sense kicks in, mainly because you have to work and test on mobile devices during development.

If your buttons are too small, you’ll know when you first try to click on them, if you put too much on a page you’ll spend most of your time scrolling. If your pages contain too much data you’ll spend forever waiting for them to load, and so on.

So now you’ve learnt from the UI master himself, the real trick is to use technology like WAPL to ensure that your wonderfully designed and interactive service works well and looks perfect on every mobile device.

Without WAPL, developing for ALL devices is incredibly difficult if you take a ground up approach. Identifying devices and adapting content will take up valuable time and resources that would be well spend elsewhere.

You can concentrate on the UI, the design (as pretty things are important too, Jakob – they help us bond with the interface) and most importantly the application.

A great idea, WAPL and the UI considerations of such an expert will set you firmly on your way to creating a marvellous mobile web experience.

HTC Magic

Stop Press: The Google Android phone doesn’t support CSS.

Or so the UAProf supplied by HTC for the G1 would have you believe. We’ve got one in the office and have recently updated its browser software. Only the new user agent profile (an XML file detailing the phone capabilities) now says that it doesn’t support CSS.

The good news for users of Wapple is that the device profiling system at its heart knows that vendors sometimes make mistakes and takes that into account. Oh, and when HTC update their Uaprof so that it says it supports CSS, it’ll know and update as appropriate!

Obviously the Android supports CSS and everyone knows that (apart from HTC by the looks of it). This is a great example of how hard it is to do device profiling yourself and why it’s so awesome that you’ve got tools like Architect available to do it for you!

Without these systems in place you’d be looking at stripped down versions of sites with no style, but instead, you still get great looking Wapple powered mobile sites.