THIS BLOG HAS MOVED

and has been relocated at http://www.memeapps.com/blog/

Android Open Conference October 2011

This was a great conference. Well organised with a good range of talks.

I found the cross-platform talks particularly relevant and interesting given what we are doing with Meme IDE. For most of our current customers using rugged-brick-phones the emphasis on design and elegance of the user interface, would frankly not be their top priority. However, for some of the software builders there, this is a reason not to use any cross-platform IDE. And understandably, the subtleties of design are clearly paramount for a consumer app.

Interestingly, in LinkedIn's talk by Kiran Prasad on their cross-platform development, the presenter sited a design rule of breadth < 4 and depth < 3 so that the user does not get lost. I tried to think how this would map onto some of our field service applications with a complex workflow and lots of information to collect. We rarely have depth > 1, but in some places we have chains of next / previous buttoned screens that are 10 or more steps wide.

Other interesting talks that add to this argument were:

* Design, Building and Architecture for Twin Towers: Android & iOS by Bess Ho
* Cross-Platform App Development with Flex Mobile by Stephen Chin
* Awesome Apps and Agile Development by Dan Clifford

Its a different world. So the question arises, is our next step with Meme IDE to make it more 'consumer capable' and relevant to this more general market? or do we stick to the customers we know and sell it as a premium field service mobile development kit?

Tricky!

Droidcon 2011

I had not been to one of these events before and I was pleasantly surprised.

The 'bar camp' is a great idea. Those who wanted to talk about something stood up at the start of the session and pitched for it. Then the rest of the first day was broken out into three tracks for the sessions that were voted in. In fact I think all the talks were voted in.

It produced a big range of talks, and yes many of them were promotional (including mine), but there were also some good technical discussions. This included a good talk about using Aspectj to weave Google Analytics code into an Android app without filling the codebase full of fluff. I would love to be able to tell you who gave the talk, but I cannot find the Barcamp speakers list on the conference website anywhere.

This event was full of consumer app developers, working on shiny devices. Where do we find our target audience of 'rugged-handheld-computer' users who are stuck with Windows Mobile 6.5 but see an escape route through Android?

They must be out there somewhere. Or, maybe they are not, and we just need to make Meme IDE more consumer oriented.

A penny for your thoughts.

Droidcon and Android Open

I'm really looking forward to an Android, Android and Android end to the week. I will be attending Droidcon in London tomorrow and Friday.
Then I'll flying out to San Francisco at the weekend to speak at Android Open. for info on my talks check the links below.

 Hopefully see some of you there.

will be tweeting all the way through @theappmonk

Meme IDE: Sketch Box in v1.13

Version 1.13 of the Meme IDE includes this exciting new feature -- Sketch Box.

This feature can be used to capture signatures drawn on the touch screen with your finger or for annotating existing images.


Android devices generally have a capacitive touch screen that requires the use of a finger or a stubby stylus. As such they require a different approach to signature capture. In particular, they need the whole screen in landscape mode in order to draw a signature by finger.




For this reason, Android has a Sketch Box function rather than a Signature control. The Sketch box is launched by a function call and has a predefined screen layout, with additional options to clear the drawing, accept or reject the drawing. I use the word 'drawing' to indicate that the Sketch Box is useful for more than just capturing a signature.


sketchBox
sketchBox(image, titleText, data, callback);
The first argument is a reference to an image resource that must be added to the resources area of the project. If this is provided then it will be displayed as a background on which annotations can be made. The image must be copied into the resources folder of the project organizer and then a reference to it should be set as a File resource entry.

If you do not require a background image then the para- meter value should be an empty string.

The second argument is the title text that should appear above the signature area.

The third argument will be the initial data for the starting data for the sketch. If this contains the appropriate base64 string then the Sketch Box will contain this initial vector image. Note that this will not be modified, but rather when the callback is invoked (the final argument) then the new vector data will be provided as its argument.

The button labels can be modified by changing the re- source properties.

Similarly, the drawing color for the sketch box is also set using a color resource.

The following example shows a simple call to sketchBox and the corresponding callback function.

function sketchbox_open() 

{

  sketchBox("", "Sign below", data, "sketchComplete");

}

function sketchComplete(encoding : String) 

{

  if (encoding <> "") 

  {

    data = encoding;

  }

}

This example is typical because it saves the encoding that is received in the callback into the global variable 'data' from which the original vector image was fetched.

Decoding Sketch Book Files
The Signature control and the Sketch Box both encode signatures in an efficient vector format that is base 64 encoded. These signature strings are typically about 500 characters in length.
To decode these strings into jpeg (or other formats), a Java utility is available. Please contact support@memeapps.com if you find yourself needing to use this.

for more information on 1.13 check the release notes in our forum

Si.

The Global Developer Challenge is open

The challenge is for developers to create and build a business utility application using Meme IDE. The developer of the winning app will receive a Panasonic Toughbook tablet. Worth over $2,000.

Build any form of business app through Meme IDE. That is the only specific requirement the rest is up to you, the submissions could really be anything from an expenses recording app, a to-do list app or even a currency converter but we really just want to see with what you can come up with. We are looking to reward development innovation from the Meme IDE beta community to stretch the capabilities of our software.

there is much more information and the entry details here

And I'm one of the judges!

Si

Is Android a Good Platform for 'Grimy' Business Solutions?

Business solutions can be divided into two on the basis of the type of user.

There are 'shiny' business solutions for sales people and managers. These are essentially extensions to an organisation's CRM system. These solutions will generally also include email facilities and may be delivered on a Blackberry or an iPhone or smart Android device, in other-words a consumer-style smartphone.

A quite different type of solution, but one that is generally higher value in per-user revenue is the 'grimy' business solution. This will usually be delivered on a rugged brick of a phone. The end users may be involved in field service activities (fixing things) or delivery activities.



The devices and app will be heavily locked down and the workflow will dictate the activities of the engineer or delivery worker.

The vast majority of 'grimy' apps are written in Windows Mobile. In fact, we can be more specific than that, because the rugged equipment manufacturers have stated that they will be sticking with WM6.5 for the foreseeable future and not migrating to Microsoft's latest mobile operating system. Windows Mobile (and even more aggressively WP7) has long been negatively viewed by reviewers and blogs such as this one from Greg Kumparak @techcrunch but still it is used and heavily relied upon in business.

So, back to the original question. Where does Android sit in all this?

My answer is that Android is well suited to this kind of app for the following reasons:

* Hardware compatibility. The hardware currently used by manufacturers of rugged WM devices is in most cases perfectly capable of taking Android, without modification.

* The long screen. Screen designs for WM6.5 business apps tend to get very tightly packed. Scrolling the whole screen does not work well, when you have an app out in the field and you are trying hit the 10 pixel wide scroll area on a badly calibrated touch screen. In Android, it is far more natural to have a 'long' widely-spaced screen that the user can wiz up and down with using swipes of the finger.

* End-user familiarity. WM6.5 has its roots in consumer phone technology. But this is a fast moving technology and people are used to the iPhone / Android style of doing things. It is becoming more and more familiar to end users.

* No stylus. Businesses buy styluses by the box full. They get lost and broken with great regularity.

* Tablet-tability. The increasing abilities of android tablets and especially rugged versions are making them a more appealing option for businesses. Some good and more viable examples were highlighted by Matt Burns over at Techcrunch back in April.


When will we see 'grimy' Android apps?

Well, they are starting to emerge, but it will probably be at least two years before they are on a par with WM6.5 solutions - at least in the 'grimy' market.

It will be interesting to see if this is hastened by Google's purchase of Motorola's phone division.

Si

Find me on twitter @theappmonk

Next webinar...

Thanks to those who attended my webinar yesterday. 

The next one coming up is next Thursday 15th Sept 09:00 PST / 17:00 GMT

(can you see a pattern emerging?) 

details and registrations for these free webinars are here.

We have put a list of dates together now so just pick any of them when you are free.

Si

@theappmonk

Requirements Engineering for Business Apps

The boundary between the customer and the developer is often a dangerous place to live. Customers think they know what they want and developers usually know what they think the customer needs. As with all areas of software development, success will only become possible when these views converge. Lack of convergence will result in disappointment at best and litigation at worst.

While this is not a problem that is confined to mobile development, it can be worse than a conventional system for a number of reasons:

* Mobile Apps are a "new thing" and customers often don't understand the design constraints and possibilities of a mobile phone platform.

* There is almost a status symbol value to having an App for you business. Even if there is no immediate operational need for such an application.

As with any situation where there is an expectations gap to be filled, communication is the solution. There needs to be a common understanding established between the customer and the developer. N.B. I use the developer in the sense of the consultant or analyst / programmer who will be responsible for developing the system. To my mind, creating another unnecessary information gap by separating the roles of analyst and developer is a recipe for disaster and contrary to the agile practices that we use internally to accomplish the development, once the requirements have been gathered. Yes, ideally requirements should be more fluid than that, but in practice customers will rarely be willing to accept an open-ended truly agile process, so we keep most of the agility internal.

Some of these points have been were picked up in an insigtful blog post by Brian Sommer over @ZDnet explaining how the requirements for business apps should be rethought to keep up with users.

We have a couple of techniques that we apply during our requirements gathering.

The first of these is about the customer teaching the developer and the second reverses the information flow and - ideally - bridges the information gap, to initiate a successful project.


'A day in the Life of'
The first of these is about the developer learning more about the current business process, and where the customer sees the mobile extension of their business occurring. The day of one of the workers using the app is spread out in a timeline, by attaching sticky-notes to a wall or whiteboard. Other contributory parts of the business are also mapped onto this diagram.

It is essential that someone who either does the job, or has done the job of the person holding the phone is present.

At the end of this kind of workshop, the developer will have a good understanding of the customer's business and be buzzing with ideas and thoughts about how to create a great solution. The customer will probably also have a better picture of their business process and also ready for the next step.

'App Workflow White-boarding'

The next step is for the developer to start drawing the App. This should not be pre-planned. It should be created in the presence of the customer with immediate feedback from them. The developer should keep control of the whiteboard pen but consult the customers, presenting their vision of the App in the form of a whiteboard workflow.

The app should support the mobile worker, not make their life more difficult. It should lead them naturally through their daily tasks in a linear manner. Modeless user interfaces where you jump around between screens and the user controls the workflow in their head are rare. As such, it is the operational people in the room who should have most influence. Hopefully they will be wowed by your insights and pleased to contribute.

Customers tend to want the App to do more than it needs to. The App development should be phased, so that each phase can inform the design of the next. The first phase should be as simple as possible.

There is of course much more to requirements engineering for mobile Apps, but I hope these techniques will give you a good start.




CodeProject

Free Webinar

Simon Monk our CTO (aka theappmonk) will host an open discussion around any issues you want raised involving Meme IDE™, its use and  the future development plans.

The third webinar will start at 09:00 PST/17:00 GMT

on Thursday 8th of September 2011.

If you plan to attend the webinar please just drop your email to webinar@memeapps.com so that we can send you out the Adobe Connect link.

DISCOVER HOW TO…

BUILD using our effortless development environment, Meme IDE™. Through its user friendly drag and drop editor for both WM and Android.

DEVELOP complex functions using the unique MemeScript™. A language created to make elements simple and cohesive on any platform.

Last week we held the first of our webinar sessions and this is second chance to catch it and speak to Simon Monk, the creator of Meme IDE. We are fully open to any questions, bugs/fixes you want highlighted, any future platform targets and features you want discussed. This is your opportunity to have input into the development.

We would appreciate your questions prior to the event so we can prepare for them, post here or below.

If you just want to drop in, feel free to sit back and view the webinar as it happens; learning about Meme IDE™, the thinking behind it, the specific technical details and where we are planning on heading. But please let us know so we can send you the link.

You can find Simon on twitter or @memestreams for more information

As we have said this is a community based beta and we want to here what you have to say!

email webinar@memeapps.com to join