It has been a while since my last post and a lot of things have changed since then. Notably a house reno. that has started again with no end in sight; a work restructure / takeover that if disclosed would see Usain Bolt’s 100m world record under threat by the media as they sprint to claim gold to win another salacious story involving government.
But this blog isn’t about that although some would probably find it a more interesting read. This entry is about a strategic planning tool that I was recently introduced to and tried first hand and the broader investment management framework surrounding it. The tool is called an Investment Logic Map (ILM) which in summary is used to assist with ensuring business and IT priorities are aligned as part of shaping a business case or ICT strategy. Now all groans aside an ILM is worth adding to your BA toolkit. If space in the toolkit is a concern then apply the one year rule and ditch some other framework or methodology because this is a keeper!
Background
Few businesses can dispute the significant costs involved in investing in ICT, and it seems even fewer can place hand on heart in faithfulness to having realised the originally stated benefits – if in fact the benefits we correct in the first instance. In 2003 the Victorian government through the Department of Treasury and Finance developed a simple but powerful framework that was committed to ensuring that ICT related spending would be targeted and prioritised before any investment was made. As a taxpayer and therefore a government representative by proxy I’ve rebadged the ILM to the KBHM – Keep the Bastards Honest Map.
A key driver of the ILM or KBHM was simplicity - reduce the detail and complexity while increasing intelligent conversation with the investor and taking common sense approach.
The Approach
The focus of the ILM is on investment management as opposed to project management. I must admit the term investment management feels foreign and out of place as part of my BA vernacular, but it does help to change the focus from a project to an investor perspective.
Project lifecycle methodologies are typically delivery focussed and success measured by whether the project came in on time and on budget. Consequently, the majority of dialogue and reporting from the project is centred on this. Conversely investment management lifecycle methodologies focus the attention of the stakeholders to grass roots by constantly asking the question ‘why are we doing this?’ The lifecycle starts with an idea and ends only when the investors (client) are satisfied with the return or have revised their benefit expectations.
Investment Logic Map
The ILM is given birth to in front of key business stakeholders or investors in a facilitated workshop where the drivers, objectives, and benefits are stated, quantified and prioritised. The drivers and objectives are essentially the problem statement whilst the benefits provide justification to why an investment should be made. The remaining section of the ILM is solution focussed, specifically what business changes and IT enablers are required to solve the problem. Proposed solutions can be facilitated in another workshop or initially shaped by the strategic project team and then presented back to the investors for review and signoff. ILM example below:
The ILM is a living, breathing document that revalidated and if required shaped during the lifecycle of the investment. The ILM is a tool that all levels of the business can engage with, and all stakeholders including IT vendors. It is a nice visual reminder for all involved parties which states why we are doing this - particularly on those larger, longer project where resources come and go.
When you see the investment process worked through and analyse the ILM you think to yourself a couple of things, 'surely i've seen this before' and 'this is just common sense stuff' - and your probably right. The beauty of the framework and tool is that it removes complexity and summerises the business problem, benefits and solutions in an clear, concise and digestable forma. It is a clear case of less is more.
Additional details regarding the investment management approach and ILM can be found on the Victorian government’s Department of Treasury and Finance website - www.dtf.vic.gov.au.
A few days ago I posted an entry of a recent successful project that adopted an Agile methodology (linkback to post). Related to this post is an article I came accross today in ComputerWorld. Written back in July last year, the article titled "Australian developer tackles Scrum software techniques" speaks of the first Australian software developer to be a certified as a Scrum practitioner - Martin Kearns at Renewtek. Although Agile methodologies have been around for many years now firsts such as these still indicate that Agile methodologies like Scrum are still gathering momentum and acceptance within industry. Here is a link to a very useful, easy to follow, high-level article on Scrum with thanks to Softhouse.
Before I share an experience with two applications recently developed using different methodologies, one Agile the other a traditional Waterfall, here’s a little background as to the origin of Agile for those who still are new to it or know little about it.
The Agile Manifesto
Back in 2001 (yes that long ago) at a retreat at Snowbird ski resort in the US, 17 self professed and recognised software guru’s got together and held a meeting to discuss the growing field of "lightweight methods". Some felt the term lightweight method was inaccurate and misleading. From this meeting and in the next couple of months a new term "agile" was spawned and with it a number of principles and the Agile Manifesto (which unfortunately also happens to be one of the most visually challenged sites I have seen) was created and signed by all participants, and soon after the Agile Alliance was formed.
As the name suggests an agile framework is quick, nimble and when adopted allows a development team to readily adapt to changes in requirements at any stage of the project. It focuses on delivering functional software regularly (typically every two weeks) throughout the duration of the project. This transparency allows stakeholders to view progress, gain confidence and make any adjustments necessary earlier, where the cost of change is least.
The success of the methodology relies heavily on clear and direct communication between developers and the business – off site development in many ways is not conducive to agile development.
There are many books, blogs, vlogs and articles which vary in detail on the subject so I will not attempt to add to this list as I am by no means an expert however, I will recommend one article. Its author Martin Fowler is one of the 17 founding fathers of the Agile Manifesto – the article is titled The New Methodology.
Agile vs. Waterfall
Something that always interests me whenever a new standard, framework, platform, process etc. emerges is the human behaviour to immediately make comparisons and spouse why the new "model" is so good and should replace the old. In this context the new (albeit mainstream now for many years) being Agile and old being Waterfall. I'm not a believer of replacing one model with another, I’m more of a fit for purpose type of guy. I'm a big believer of extending your knowledge and toolkit to allow you to adapt your approach for different clients and situations as needed. Although I am big advocate of Agile development; I don’t however think it should be used in all instances as it does come at a cost – but more of that later.
An Example of the Benefit of Agile Practices
The Project
The project was to develop a data capture application for use in the field from a mobile device such as a PDA, or within an office environment from a PC via a browser. The web and mobile applications were developed by a variety of vendors using different software development methodologies - the mobile application using a traditional Waterfall approach and the web application adopting Agile practices.
The Difference
Earlier I mentioned that I’m not one for replacing one methodology with another, but rather choose the methodology which best suits the situation. Unfortunately the mobile application which was developed in a traditional Waterfall manner was not successful. Looking back I think a large part of this blame can be apportioned to the methodology chosen. If an Agile approach had have been taken the outcome I believe would have been different, here’s why:
- Mobile development has risks. Developing mobile applications, particularly those with extended complex functionality is still largely new ground and brings with it added risk. Agile development assists to minimise risk or validate perceived risks early. In Story Meetings I prefer the developers to tackle those risk areas first to give the team the maximum time to respond and adjust as needed.
- The vendor chose to work off site. This made communication and regular reviews of progress difficult which in turn stifled delivery. Conversely, typical Agile projects recognise the importance of being on site wherever pracitcally possible.
- Accountability through delivery. The developers of the mobile application although quite skilful and intelligent were not necessarily time driven or well managed. Developers with such traits cannot survive long-term in an Agile team where the focus is on self-management and transparency through regular delivery.
- A prototype is not enough. Although a prototype was developed it only served to validate the UI and not the business functionality. Introducing Story Meetings though an Agile approach would assist developers to focus on the areas of greatest importance to the business. Story Meetings coupled with regular functionality drops would have minimised the amount of change required later in the project and the number of defects found during UAT.
But it’s not all rosy
If anyone try’s to tell you that there are no shortcomings to an Agile approach, "tell him he’s dreaming". Some gotchya’s to consider:
- Not ideally suited to large, off-site development projects especially with an untried and trusted vendor
- Developer pairings for ‘bug’ fixes or simple well documented changes places a uncessary financial overhead
- Can be seen as an excuse for little or no documentation – design or technical. This is a big one and one that I'll expand on in a later blog
- Organisations with little process or significant manual procedural overheads restrict the teams ability to be agile
Needless to say that the web application developed using an Agile approach was delivered on time, on budget but equally important through the business seeing regular deliveries it attracted true business buy-in and spawned a number of other development opportunities for the team.
Marine Safety Victoria (MSV) conducts the Personal Water Craft (PWC) Courtesy Rider Program throughout the summer boating season. The program is designed to educate Personal Water Craft (PWC) riders about their operational and behavioural responsibilities when on the water.
The PWC Courtesy Rider Team visits metropolitan and regional waterways across Victoria over summer, with a particular focus on areas where PWC riding is popular.
The program promotes safe and courteous operation and aims to reduce the number of incidents and complaints related to the use of PWCs in Victoria by encouraging safe and courteous behaviour on the water.
Operators of the program will be equipped with a PDA running the Courtesy Rider program developed with Dexterra 4.0. The application allows officers to capture breaches of non-compliance, where the breach took place, and perform other functions such as verifying the vessel registration detail through a vessel lookup function.
Example Screenshots
Below are some examples of pages within the mobile application.
Each device is paired via bluetooth to an EMTAC Trine GPS unit. The GPS location is represented spatially within the application via GTViewer.
GTViewer was chosen as the spatial product as it was product which could be fully integrated within the Dexterra framework, and it carried a minimal footprint compared to other more well known products such as ESRI ArcPad and MapInfo LBS. In an architecture where device resources are limited running a separate spatial application in parallel with Dexterra would have been suicide.
Before the official launch of the application I got to have some fun on the water with a couple of the Marine Safety guys as they put the application through it’s paces on the water while riding their new supercharged PWCs, whilst I observed from the dry and comfort on the zodiac.
Conditions were bright and clear but with a wind of around 15-20 knots at times which made it choppy for the guys. To my surprise I was impressed with the stability of the jet skis when stationary. There was little sideways movement and their craft appeared more stable than the boat I was on. More importantly and to my relief the application survived, both from a usability and functional perspective.
It has been a long road to get this application out the door, and there have been many learning’s. The journey is set to continue as we look to upgrade the version of Dexterra we are on, investigate alternate hardware such as UMPCs and generate interest from other government and private enterprises – so stay tuned.
In the Video section of my blog is a short spare of the moment video of a simulation between a courtesy rider officer, and a member of the public. The purpose of the video was to demonstrate the context of use of which the application will be used, and what challenges the workers and us designers were faced. The video was taken with the in-built video camera on the imate pda2k. Apologies for the poor picture quality and my capture skills, note that the sound has been deliberately ommitted to protect the guilty.
Summary
9/10 Exceptional. One of all the best if not the best ultra portable devices i’ve seen so far. This gem can play with and compete with its bigger and more powerful ultra laptop uncles as well as teaching its UMPC cousins more than a thing or to when it comes to design, balance and power.
Weighing a modest .99kg it felt lighter when cupped in the forearm and felt significantly lighter than the Samsung Q1 Ultra which weighs in at .7kg. Simplicity in design I feel is underrated generally and even more so in mobility – its really a case of less is more. The Fujitsu designers have kept this in mind, and their years of experience in mobility telling in producing an extremely well balanced unit. This device is sleek, simple to operate and powerful enough to practically use in the office or out in the field.
Specifications
Check out the official Fujitsu website for the p1610 specifications.
Battery Life
Battery life is always a challenge when it comes to mobile devices, however the low voltage core solo CPU and low voltage graphics card assist greatly to preserve as much battery as possible as well as keeping heat to a minimum. I’ve read a number of other reviews which said that this device can get quite hot, however this is not my experience. When on the charge the charger adapter can get hot, but the device itself was ok.
Range of Accessories
One of the things that really impressed me with the Fujistu p1610 were the number of accessories immediately available, cases – ruggedised, bump and portfolio, extended battery, port replicator, in-car charger and more. Check out http://store.shopfujitsu.com/fpc/Ecommerce/NBAccessory.jsp?model=P1610 for a complete listing.
Manufacturers like Samsung, take note…if your going to spend millions putting out a device make sure you provide the right accessories to compliment both in-field and out of office use. An extended battery, wireless keyboard, mouse and portfolio case don’t count!
Performance
Performance was solid without being mind-blowing – mind you I was using the XP tablet version, running Vista may have resulted in a completely different experience. Microsoft Office apps ran fine, processing images and video was no trouble. It had no trouble playing avi’s directly from the USB off the standard battery.
General web browsing and connecting to the office through a NextG USB wireless card performed adequately. It would have been interesting to see how our mobility app would have performed but unfortunately it can only run at the moment on a pocket pc o/s – but more on Dexterra later.
Being slightly larger than most UMPCs the p1610 gives you the additional flexibility of a usable keyboard (for most) and room for all the necessary ports and connections and the luxury of two usb ports. All external buttons are recessed to avoid activation when bumped or moved, shock sensor that can be configured to protect the HDD, quick screen rotation at a press of the button, the list goes on and on.
Although some people may think the p1610 is just a confused device – it is an ultra portable laptop or a UMPC, I guess it doesn’t really matter as it can hold its own in both domains.
Not so good
Overall it’s hard to find something bad to write about this device…but for some the price may be a prohibitor, but most people who have bought any of the Fujitsu mobility devices, in particular the lifebooks, most say that they are worth the money.
The swivel hinge that rotates the screen to turn it into a tablet feels somewhat flimsy. I would feel more comfortable if the hinge was stiffer. I don’t know how it would hold up with constant use, I guess only time will tell – but it would be a shame it this became a point of failure. The virtual keyboard is average, but having said that I’ve yet to see a good one bundled.
If anyone has purchased a p1610 with Vista, or the p1610 with 3G please drop me a line and tell me how it performs.
Summary
7/10 Solid performer without being stunning. All key features provided. Some usability issues, poor screen readability and bulky car charger bring this device down a peg or two.
My Dad recently brought the Navman F20 for work specifically for travel within country and rural areas in . Like any new piece of technology he gets, I’m the guinea pig.
I had the F20 for a couple of weeks and used it mainly on short trips in and around Melbourne. Mounting the F20 to the dash was straight forward. The large suction pad once snapped into place made the device rock solid even traveling at high speed over bumpy roads.
The 3.5” screen was adequate to allow for clear viewing of where you were, and where your next turn was. Switching between screen modes was made easy with a single button on the front panel.
The level of detail on the bundled maps was sufficient in detail. Some might say they don’t provide enough detail, but for me, less details makes viewing where the heck your going easier.
Specifications
Check out the Navman official website for F20 Specifications.
Good
I found the interface easy to use. Not too many buttons to choose from, and the target size sufficient for even the fattest fingers.
The F20 comes with some intelligence. Upon entering a destination the It detects if route has tolls and prompts you to accept or to calculate a toll free route.
Good battery life.
Well priced.
Not so good
Although the F20 comes with an inbuilt anti-glare feature, this did little to stop the screen becoming unreadable most of the time in even moderate light. You could argue that this is a cleverly designed built in safety feature to stop drivers being distracted from looking at the screen.
Contrary to other F20 reviews, I found the GPS tracking slow on startup. Connectivity seems to work quicker and more reliably when stationary.
Although you can save a location as a favorite, you cannot add a label to it. After entering a number of locations you can quickly forget why you bookemarked it to begin with.
The cigarette lighter car charger is long and intrusive. In some manual cars (like mine) the gear stick when shifting into first collides to the side of the charger.
Annoying
A big bugbear of mine is when you have to shell out extra dollars to receive updates to a product you’ve already purchased. I know I should build a bridge and get over it, but honestly, vendors if your listening STOP! To receive updates you have to buy the Connectivity Kit for at about $40AU.
I attended my first usability conference about 5 years ago where I was confronted with the term user-centred design. Admittedly I was uncomfortable with the term, to me it was one of those touchy feely fuzzy terms used by designers who walked around with their head in the clouds. However, after witnessing the practical side of it, I’ve become a strong advocate and have not looked back.
For me, one of the understated positives of user-centred design, is that it takes the ‘ego’ out of the design. For a designer I imagine, there is nothing more humbling than to sit in on a usability session where a user struggles with overly complex navigation to a point where they admit defeat and abandon the application. User-centred design is a must for any application design and for mobility applications has to be nonnegotiable!
Most designers are passionate about their designs and become somewhat agitated when told that their design does not work for a particular technical reason – and I sympathise. The reality is that mobility at the moment has many factors working against it and most of these are centred around technology limitations. For a design to have a chance in mobilty these limitations must be understood and the designer pragmatic in their design approach.
To understand the importance of user-centred design lets first look at some of the practical differences between a typical J2EE in the PC office environment (sorry .Net guys) and that of a mobile application used in the field.
Environmental factors
Office settings provide a safe, often well controlled, established environment with which to work. Connectivity is guaranteed at an optimum level and environmental conditions, temperature and light are moderated (our office not so well at the moment but you get my point). Although application support is never perfect it can be provided on-site or remotely.
A Road Warrior on the other hand has varying experiences in a typical day. Our client at the moment has field workers who spend their day travelling, often long distances, on water. Their environmental challenges include varying degrees of light, glare - particularly off the water, sea spray and to top things off, motion. Their technical challenges range from poor battery life, signal stength and bandwidth fluctuations. Their applications cannot be designed with an expectation that connectivity can be achieved. Application support is limited and largely relies on self diagnosis and resolution and in some cases resulting in the worker returning to base.
Physical device limitations
Presently our water bound officers are using a PDA consisting of the following characteristics:
§ Smaller screen size and resolution - 3.5” screen, 240x320
§ Restricted processing power – 400 Mhz
§ Limited memory – 64 MB RAM (killer)
§ Cut down operating system - Windows Mobile 2003 se
§ Limited bandwidth – CDMA and EVDO. Due to remoteness of use, bandwidth is generally limited to CDMA network.
I understand that PDA devices have evolved somewhat, however they are still limited to a 3.5” screen or smaller with the current trend of manufacturers providing 2.8” as the new standard. There are some devices which provide 128 Mb RAM which is an improvement on the 64Mb generation 2 devices. Whilst the HSDPA network is available here in Australia this is little consolation to our workers who will be spending the majority of their day in areas out of coverage.
Type of Worker
To all the field workers I’ve met forgive me for what I’m about to say. The type of field workers that I have met are generally not
computer savvy and this needs to be taken into account when designing mobile applications. It should not matter, but it
does. Most mobile devices, be they a smartphone, PDA, UMPC, or Tablet require a higher level of user savviness than
required for a PC. Device input and turning on and off features are different, especially for those running a Pocket PC
operating system. Pocket PC devices have a different navigation model to a PC operating system and require higher levels of
user involvement. Look around as there are some great pieces of software out there which can make life easier for the
workers. Quick sidetrack, for those considering to deploy a mobile application I strongly urge you to look at a product called
Kiosk Engine made by Spb http://www.spbsoftwarehouse.com/products/kioskengine/?en.
Kiosk Engine allows you to control what applications are made available to your workers. When the device starts you are presented with one page which lists the applications that are available. The page effectively becomes a psuedo desktop. We’ve tried it, and feedback from the guys has been extremely positive. They like that similarly to the PC desktop paradigm, all their applications are located in the one spot and when they exit the application they are returned back to their desktop.
Paper Prototyping Is Not Good Enough
The reality is that paper protoyping although better than no protoyping, does not work for mobile applications. It can be used as a discussion point to validate the businesses requirements and as a starting point for a designer to work on a screen layout but that is where it ends. When it comes down to it, it loses its effectiveness as soon as you walk out the door. Paper prototyping cannot effectively represent some of the considerations mentioned earlier such as glare, varying lighting conditions, wind and water.
To properly exercise the different interaction and design of a mobile application to that of a PC, a higher fidelity more realistic prototype is required. Our team learnt this the hard way. We designed and refined a mobile application design using feedback received on a paper prototype. During testing of the application we took it out into the field to get some feedback and found some usability issues which affected how the officers interacted with the application. Some of the feedback included inadequate contrast of buttons to indicate sufficiently whether a button was active or inactive due to sun glare, to size of buttons and spacing between objects. It is important that the button and field controls are of sufficient target size for the user, particularly in our case when the context of use is on water where motion is involved. Where possible I would recommend to only show button controls if they are active and size them appropriately. Don’t be afraid to try different contrasts. We found that white text on a dark background where glare is involved can be more effective than black on a white background. The thought of this will probably send most designers into a fit, but they are not the ones who will be using the application…bring them out into the field and let the prototype do the talking!
A question that each organisation faces when implementing a mobility platform is deciding what is the most suitable upgrade path. In all likelyhood, the answer to this question will influence the type of mobile device. This is a question that our team has been grappling with over the last few weeks.
Currnet Hardware Platform
Our client is running a mobile application on a PDA (i-mate PDA2k EVDO). The model is of significance as it has been discontinued, and the network to which it connects to is being upgraded to HSDPA, rendering the devices useless for any in field connectivity. The other point is that the current form factor chosen is a PDA. Choosing a PDA as the form factor, like it or not, automatically locks you into an operating system. Unlike a PC, with a PDA you cannot simply install future releases of the OS onto your device.
Device Features
Four key questions to ask:
1. Do I require in field connectivity? If so:
a. What coverage do I need?
For this client in field connectivity is required, not just in CBD Melbourne, but in regional and country Victoria, on land and water.b. What data transfer mechism best suits the type of use and amount of data being transferred?
Large amounts of data are required to be transferred, text and images. HSDPA or WiFi 802.11b/g best suited.
2. What is the minimum screen size required from a usability perspective?
Our clients context of use is outside, typically on water where glare, salt water and motion all play a factor. A minimum screen size is 3.5”.
3. What is the appropriate amount of memory (RAM more important than ROM), and CPU?
128mb RAM, 500mhz or greater CPU.4. What is the preferred operating system?
Windows Mobile 5 vs Windows Mobile 6 http://blogs.msdn.com/jasonlan/attachment/1904298.ashx
Based on the answers to these questions the bredth of choice is limited. After conducting a search for suitable devices it was interesting to note the following:
§ Only 4 devices (11%) provide mobile data connectivity which have a 3.5" or greater screen. All devices running WM5 not WM6.
§ No WM6 devices currently support a screen size larger than 3".
§ Data suggests that WM6 devices which provide data connectivity are limited to screen size of 2.8". More value placed on providing a more conveinient, smaller form factor than providing additional screen size. The traditional PDA screen size of 3.5” is limited, and users are forced to consider a different form factor such as a UMPC.
§ Majority of device manufactures have product availability in Australia.
§ No PDA device currently on the market which has device features.
For a copy of the PDA comparison spreadsheet send me an email at pdaulerio@optusnet.com.au.
Useful Links
http://pdadb.net/ - Comprehensive listing of PDA and SmartPhone devices including specifications currently on the market as well as a listing of devices pending release.
http://www.umpcportal.com/journal/ - Comprehensive listing of UMPC devices, including site rating.
Typically an organisations foray into the mobility space starts with management deciding they need / demand access to email and calendar 24x7 from a PDA type device. This typically results in a Blackberry solution limiting what applications can be built and deployed to it (more on form factor selection in a future blog).
Planning is typically kept short, with insufficient time spent understanding different contexts of use which ultimately shape the mobility solution(s) required.
Take the time to understand your mobile workforce. Survey and speak to your workers to appreciate each of their specific requirements. From here a profile will start to emerge of the different worker types requiring mobility in your organisation. Here’s what we did:
§ Collected, analysed and collated feedback from our customers
o surveyed user base (800 staff)
o conducted one on one interviews (50 staff)
§ Collected mandatory and preferred customer requirements for “desired” services
§ Built a profile of remote access users based on frequency of use, type of use, and application / information requirements
§ Assessed the usability and accessibility characteristics of existing services provided
§ Identified potential external influences which might affect the future of the services provided
§ Identified gaps in current services, processes and policies
From the data gathered we identified eight primary modes of access and twenty-four unique user profiles, much more than we expected or thought possible. The other finding worth noting was that 72% of our staff worked in either 2 or 3 different modes to perform their job role.
Of the eight primary modes use, two had specific mobility requirements that needed a small form factor solution, such as a tablet, PDA, or UMPC.
Road Warriors
“I work in the field and I need my office documents & biz apps with me”
Road Warrior workers describe staff that spend up to 5 days a week in the field (metro, regional & country), performing business functions and require application and corporate environment access during the day in either a disconnected or connected state.
This type of extreme mobility is conducive to tablets, slates, and small form factor devices (PDA's, and UMPC’s) and is typically indicative of wireless connectivity requirements.
Characteristics include:
§ Located anywhere in state, visiting multiple sites/locations in one day
§ No data point/network access available
§ Collecting structured business data in the field
§ Away from primary office location for extended periods (multiple days)
§ High duration and frequency of remote usage limited to after hours and weekends
Mobile Workers
“I'm in a constant state of travel”
Describes staff who are away from their office environment (or any network connectivity), either in City, Metro, Regional or Country for a significant and critical duration of time during which it is essential to have direct communication (email & calendar) and access to information (MS office documents).
Characteristics include:
§ Executive staff away from primary office for most part of their day with no data point or network access but access to desk/pc
§ Must be contactable to respond to time critical issues
§ Perform managerial tasks (authorisation/approval/document authoring)
Future postings will focus on delivering mobile solutions to staff fitting the Road Warrior profile.
For the last couple of years I’ve spent part of my working life designing and writing specifications for mobile applications. As dealing with any emerging technology, the road to success has been far from smooth, in fact painful at times, no make that excruciating!
Whilst on this ride I’ve learnt that every decision in relation to mobility needs to be carefully considered and its implications measured and calculated as much as humanly possible. Compared to designing, for example, a J2EE application you don’t have the luxury of oodles of processing power, vast amounts of memory, and a complete arsenal of design and development tools. The result of an unconsidered decision can mean the difference between delivering a successful solution vs. an expensive prototype.
In researching to learn from other people’s experiences I’ve found little documented that covers the spectrum of what should be considered – from choosing a suitable form factor, to knowing what frameworks and methodologies to follow.
So due to the wonder of technology, and the Vox crew, I’ve decided to setup my own blog, to share first hand my experiences and findings that might help some of you who planning to embark on your own mobility journey.
If your a little impatient like me and cannot be bothered reading through all the posts (or most likely waiting for me to write them), I’m happy to have a chat, drop me a line at pdaulerio@optusnet.com.au.
