Mazda MX5 Overview and Modifications

Mazda MX5

It’s getting towards Christmas and most of the Enterprise Mobility sector seem to have gone skiing so here at MobileWorxs we’ve decided to veer off on some random topics we are 71.5% sure you will enjoy. This blog will cover the Mazda MX5 early MK1 the MX5 with pop-up lights !

So, MK1 MX5 (Miata in the US) from 1989 to 1998 is the most popular sports car in the world. And it’s easy to see why. A lightweight 2 seater, front engined, rear wheel drive convertible with a fantastic bulletproof engine. They have great balance, great handling and quite simply everyone wants and loves a convertible in the summer no matter how old. You can pickup a mk1 now for well under £2k. Lots under £1k. Just beware of buying a rust bucket.

PhotobucketJapanese imports, called the Eunos, tend to be a safer bet when looking for a rust free example. They don’t salt their roads in Japan hence they don’t rust anywhere near as much. Plus they drive on the same side (aka ‘the correct side’) of the road. UK models with no rust can be found if you look long and hard enough. It’s just a waiting game and be prepared to travel if you are after the immaculate example.

The twin cam engine in the MX5 is available in 1.6 & 1.8. Some 1.6 engines were detuned to a rather pathetic 89BHP, so a 1.6 at 115BHP or 1.8 at 130BHP is recommended for grin factor. The engine is the outcome of studying examples including the twin cam engine from a Lotus Elan, which of course Mazda improved. With regular servicing changing oil, plugs and filters these engines go on and on.

But is it a Hairdressers Car ?

But it’s a hairdressers car I hear those doubters say. Until you have driven one or been a passenger on a spirited drive you can continue to be wrong. For the money you simply cannot beat it. Get a Mazda MX5 on a racing circuit and it’s true potential will show. The MX5 can outperform cars many times the price. All the mechanical parts on the car were over engineered meaning unless you’re a driving Jedi (meaning you’ve been trained on a circuit for many hours) the cars ability will long outreach the drivers.

Photobucket

There are plenty of modification parts available online. Second hand parts tend to be more for the 1.6 than the 1.8 but it depends what part you’re after as they obviously share a lot of common parts. The brakes on a 1.8 are a big improvement over the 1.6. This is a regular upgrade. Other common upgrades tend to be suspension (provides the biggest improvement as a one off), air intake, after market exhaust. There are many more such as seats, bracing, silicone coolant pipes, ECU chipping, 14 degree timing mod, 4-2-1 manifold, poly bushings, wheels, tyres, hardtop, roll bars, steering wheels, braided brakes lines, brake pads and discs etc. Modifying to this level can be an expensive game.

The above mods don’t actually increase BHP, maybe by a few horses but not a lot, it’s more a placebo effect but a good one at that. Major power increases can only really be achieved by upgrading the engine internals or forced induction (bolting on a turbo or supercharger). These upgrades can be very very costly. If the turbo/supercharger setup hasn’t been tuned correctly and you run the car for too long, too hard then BANG goes the engine. Luckily there are very helpful chaps who can help with this.

There are a few MX5’s which were produced with a turbo. These are very rare to find and costly.

MX5 Information

There is masses of information online about MX5 MK1. In the UK you can visit MX5OC or MX5Nutz, in the US there is Miata.net and another 20 more.

As said above, for the money you can’t beat it. The car excels at cornering but can be let down by the slow straight line speed on a race circuit. Since you’ll be sticking to the legal limit of 70mph on UK roads this doesn’t make much difference.

What could MobileWorxs add? How about a GPS unit to monitor your racing lines on the track. Or a funky on dash mounting bracket for a rugged tablet pc. Ok Maybe not…

Have Merry MX5 Christmas !

Integration for Enterprise Mobile Applications

Integration for Enterprise Mobile Applications

The most common and sometimes most complex issue overlooked in a mobile project is how to connect to data in a host system often referred to as “back-end” data. With the vast array of ERP and business administration systems around integration for enterprise mobile applications can be a long process.

 

It is quite rare nowadays to find a company with no IT system in the back office. Usually it is the paper based system of the mobile workers that are the issue, with businesses focusing on mobile application features, rather than how to get data in and out from their existing systems. Commonly we see backend systems starting at the basic level of Excel and MS Access right up to complex systems such as SAP, MS Dynamics etc running on SQL or Oracle. With large companies running multiple systems.

Different development approaches will provide different integration paths. If coding using a platform there will be a number of integration options out of the box, if traditional coding it very much depends on the developers experience.

Integrating to systems is performed in two stages; one is pulling the data out of the host database of to use on the mobile devices, the second is to update or insert backend system records with results from the mobile device. Both can be performed via a number of simple routes, such as SQL queries, web service calls,  import and exporting CSV/XML or similar files and finally moving towards the complex end by using API’s (Application Programming Interface).

SQL queries can extract large amounts of data from specific tables or connect to a view (pre-configured table that’s results matches specific criteria) if one has already been setup. Some logic is probably required here to make sure records are not overwritten. Inserting/Updating back to an SQL database is usually performed per results set.

Web service calls provide real time access, which can also be called in the field over 3G. This method is OK where result sets are small. Some time can be saved as the web service will have already been provided by the host software company. As above some logic is probably required here to make sure records are not overwritten.

Importing/Exporting CSV, XML files can be easily done on a batch process and avoids the complexities of coding the API. We tend to find this is used an interim/testing process, but can also reliable when live. The issue is it does tend to add another failure point. Once again some logic is probably required here to make sure records are not overwritten.

Using an API means the solution can be coded to call specific function and parse the given data. The API essentially handles all the data and updates the correct areas of the back-end system. An API integration can be a seamless full integration, but is also the most time consuming and requires knowledge of both the mobile and back-end systems. It can also mean continual high development costs if the complete solution is ever changing.

There are numerous other options and varieties of the above. The choice made is very much dependent on questions about the integration options the backend system can provide and accomodate.

Key Integration Questions

  1. How many users need to access the data.
  2. How many need to access it at any one time.
  3. How many results and results sets there are.
  4. Are results sent one at a time or in batch.
  5. How are the mobile devices updated.
  6. Does data reside on the mobile devices.
  7. How do devices receive new data
  8. Is the data all stored in one location.
  9. What is hte nature of the in house systems architecture.
  10. how many systems require updating.
  11. What are the redundancy and failover setups……the list can go on !

In the first phase of testing the integration is usually the major testing piece as if data doesn’t flow correctly the solution is somewhat useless. No matter what backend system is being integrated to as long as a detailed testing plan is drawn up and completed there is much greater chance of project success. A key factor in your long term return on investment.

Not discussed in this blog is how integration for enterprise mobile applications can differ from consumer to enterprise applications. Well…. An enterprise application should be a complete solution capable of seamlessly integrating into in house backend system literally a modern day lynchpin. A consumer application downloaded from an Application Store connects to the developers hub and if possible may connect to in house data. Generally this is not the case and they operate standalone or semi-standalone.

How can we help you with Integration for Enterprise Mobile Applications ? Learn More

Experience our Apps Book a Demo or Visit Here

 Subscribe to our Blog in a reader Or by Email

Mobile Printing in Enterprise Mobility Applications

Mobile Printing in Enterprise Mobility Applications

Wireless Mobile Printers come in various guises

When developing a project for your remote workers one consideration is how to incorporate mobile printing in enterprise mobility applications in the first place. Is there a need to print a receipt or report for the customer contact on site? There is a big choice of rugged mobile printers all of which provide different features and most importantly can print the correct label receipt or report you require.

Most people new to the enterprise mobile apps tend to think of having to carry a huge heavy printer. In fact mobile printers can be very small like the Zebra P4T clipping onto a belt or on a shoulder strap. They can also be very large printer fixed to the inside door of a van. It all depends on the size of label receipt you want to print.

One big question to ask is does a receipt or report need to be printed on site? For this scenario think of a civil enforcement officers Fixed Penalty Notice application when the vehicle or person in question must be issued a ticket on the spot. Otherwise if you have the customers email details why not just email a .PDF. In some cases a print at the point of service is not a definite requirement such as for parcel delivery companies who handle all documentation via email or online.

Two main types of Wireless Mobile Printer Technology

Thermal Transfer and Direct Thermal.

1. Thermal transfer has two main components. It uses a carbon ribbon, using heat to “transfer” the carbon onto the media (the receipt or label). The results on the printout are much crisper than the Direct Thermal but it does mean costs a greater as you’ll need to buy new ribbons and new media.

2. Direct Thermal printer uses carbon coated receipts/labels, again using heat, but this time to score an image into the media. There is only one major cost for this – buying media. The heated print head does wear out eventually as you’d expect, but it can last the life of the printer is most uses.

Both have their advantages and disadvantages. If labels/receipts are required to be hard wearing, scratch resistant, print high quality images i.e. 2D bar codes, long shelf life or in direct sunlight then Thermal Transfer is the best option. If basic layouts need to be printed, stored in plastic wallets or out of sunlight, only required for short periods, then Direct Thermal is the way to go.

Mobile Printing Media

“It all starts with the label…. “There are numerous types of media available – ranging from the very glossy, very hard wearing to the basic till receipts you get at most stores. They are available in almost every size you can think of and can be provided with pre-printed text on one side. Very useful for store return policies or payment details for a parking fine.

Wireless Mobile Printers for Direct Store Delivery and Van Sales

Full Page Rugged Printer

Impact printing is not used a great deal in many enterprise mobility projects other than route accounting or direct store delivery as it is called in some markets. Here the requirement is to print a full page receipt in some cases with multi part paper. Most of the above considerations still ring true – but what to use? An office printer would not be rugged enough. As far as we know Intermec are still building the 6822 a behemoth of a printer but very well suited to this environment.

 

Communication

Communicating with mobile printers is done in one of three ways; Bluetooth, Wi-Fi and Direct Cable.

  1. Bluetooth. Ideal for ad-hoc connections in the field, does not rely on anything else, can limited by distance and not considered the most stable connection. But this is the most popular choice for mobile printers.
  2. Wi-Fi. Fast, stable, but does require the device and printer both to be in Wi-Fi signal range.
  3. Cable connection. A direct cable connection from device to printer. This is the most reliable option but also the must inconvenient if you need to disconnect from time to time, and means something else to carry.

But defining communication medium is only half of it. The next part of the challenge is to get the printer to print the label exactly how you want it with all images/bar codes etc. For a device to talk with a printer it has to do so via the printer interface. Each manufacture has their own printer language at this point. Zebra uses ZPL (Zebra Printer Language), Intermec Printers use IPL (Intermec Printer Language), and so on.

Print commands in each of these languages can be a bit of a challenge. Most printers also have a line print option, and depending on the software can essentially print a complete printer layout that resides on the PDA device. Whatever option the device must have the drivers locally installed to communicate with the printer.

New printers on the market can now accept .csv files and similar file via print management software tool, or can print directly from notepad. In some cases new printers can call and receive from a web service meaning a device may not even be required. Obviously this has very limited operations.

Finally if carrying an extra piece of kit is a big issue maybe a mobile printer is not required. Alternatives are IP printing back to a printer in to office, PDF generation and email, back office staff printing and posting documents, or online access only for customers.

Mobile Printing in Enterprise Mobility Applications 4 Things to Think About

  1. Start with the application. Does the customer need a printed “something” at the point of service?
  2. Media. What sort of material does the receipt or label need to be made of to suit the enviroment?
  3. Hardware. What sort of wireless mobile printer will suit the process?
  4. Mobile Application Development. How can you make your rugged handheld or rugged tablet pc generate the right label at the right time containing the correct information? On our platform the built in print layout designer takes a lot of the hassle out of cutting code.

How can we help you add Mobile Printing in Enterprise Mobility Applications ?

 

 Subscribe to our Blog in a reader Or by Email

 

Cloud Solution or Thick Client Platform 3G

Cloud solution or Thick Client Platform 3G

Android Smartphone
Android is gaining market share in Enterprise Mobility

Having defined the business requirements the next choice is deciding if the mobile application should run as a cloud solution or thick client platform 3G solution whilst considering the connectivity needed from device to server.

A cloud based thin client solution is an application accessed over a web browser. There is no application or data stored locally and all processing is performed on a central server just like a normal website. A thick client solution uses a locally installed application which sits on the device along with all data required. There are many pro’s and con’s with each and a number of questions need answering to decide which would suit. There is no ‘best’ option as all requirements are different.

Cost does play a factor in this for devices they will run on. Most people nowadays have a Smartphone, be it an iPhone, Android or Blackberry. These are all capable of running as a thin client. This means the business has no or little outlay for the devices if employees use their current units, BYOD. But tied to this comes issues with connectivity, speed of the application, and data costs. All major return on investment considerations.

If the application is used in areas of poor or no signal then a thin client solution would not be recommended. If there is no data connection a thin client application cannot work. A thick client would be recommended to enable the user to work offline as all the work orders would have been downloaded to the device over Wi-Fi or 3G prior to going on site.

A thick client can also connect to backend systems as standard to receive new work orders, send completed work orders back to a server, or request data in real-time. This is sometimes referred to as a ‘Smart Client’. Connecting to backend system when in the field depends on the quality of 3G signal. When the signal is good a thick client can synchronise data to receive an updated jobs list and send back all saved results.

A strong 3G signal or over Wi-Fi will mean a Thin client can access the web service easily and quickly, but should this drop out the user cannot continue. Some thin client services can download temporary data so the user can continue to use a thin client to a point. But beyond the temporary data the user is stuck. A poor signal results in a slow lagging thin client application. This can be very frustrating for the user.

Location is another factor to be taken into consideration – Where will the application be used specifically? If the application is required to check boilers or air-con units in basements and cellars then again it is very doubtful there will be any signal. Likewise if going to rural areas away from towns and cities.

In a lot of built up areas signal is now generally very good although congestion can be the real problem. This is very good news for thin clients. Likewise when working in Wi-Fi hotspots or buildings/warehouses with very good Wi-Fi coverage. This is still not to say in this instance a thick client should be discounted.

When in the mobile application development phase it is worth thinking about where data needs to be stored. As a rule .NET thick clients are generally much quicker than thin clients. As all data is stored locally all business logic is performed on the device rather than a web server. Granted if there is a vast amount of logic to calculate a PDA may be slightly slow. This is where a rugged tablet PC with a much faster processor i5 can be used in place.

3G data costs are another area to consider, especially if the users are providing their own devices. A thin client will use much more data than a thick client. This is because a thin client requests everything to be displayed whereas a thick client only requests new data and sends results. A thick client solution can even do away with 3G connection all together in some cases. All the jobs could be downloaded in the morning or day before over Wi-Fi, removing the need to request new jobs through the day.

The key question is: In the Cloud Solution or Thick Client Platform 3G debate without guaranteeing a connection over 3G or Wi-Fi is a Thin Client solution really sustainable?

 Subscribe to our Blog in a reader Or by Email

Cloud solutions Vs Thick Client Platform – Support

Cloud solutions Vs Thick Client Platform – Support

Motorola PDA with Mobile App
.NET devices still have a lot to offer

When comparing Cloud solutions Vs Thick Client Platform .NET platform solutions, cost is usually the first starting point for businesses as a cloud solution means the applications can run on less expensive devices such as Android handhelds, which can be the starting point for thoughts about BOYD. But, how do you support a roll-out with mixed operating systems?

Devices have been covered in a previous blog so here I will focus on the software issues, both local and server. Yes Android, Blackberry, iPhone iPad devices can be considerably cheaper then Microsoft .NET devices but this also means you’ll need to support several platforms rather than one. What will that do to your total cost of ownership?

Updates for the multiple Smartphone platforms are never scheduled at the same time. This means on day one all the Android devices may update to the latest OS version, the next day all the Blackberry devices may update. There is no guarantee devices will still continue to work with the application after an update and finding a fix for each platform can be very different and therefore difficult.

When HTML 5 applications are being developed, they are developed for specific OS API’s, i.e. Android 3.0. When the Smartphone is updated to the latest version 4.1, a or a new device is purchased, the application will need to use the 4.1 API. In the best case scenario the application will have to be re-built, tested, and re-deployed. This is a major task in itself as cloud based solutions do not incorporate development and application & data synchronisation as standard. In the worst case scenario the application code will have to be edited. This is a very lengthy process in which the mobile application is out of action.

Using a thick client based mobile application development platform with Windows Mobile devices the applications are fully backwards compatible and any platform updates are issued by the administrator not the network provider. This provides a hassle free deployment with simple support as all devices are using the Microsoft .NET framework. It also means access to a wide variety of devices such as

The thick client has the ability to lockdown the unit so the user cannot access important system files, or spend hours playing games. The device is there for a purpose and can only perform the tasks the application allows. How do you lock down a personal Smartphone belonging to your employees? In short you can’t. You can provide the facility to access a web based application (if they have an internet connection) but you can’t guarantee they are not texting, playing games or surfing the internet.

The last point to touch on here is how the application can be updated. The application for the HTML 5 platform requires coding, a lot of testing for each OS, compiling, and then deployed to a central server location. The coding could take days or weeks depending on the update. In the thick client platform the update can be made in minutes to hours and deployed instantly. Yes the HTML 5 application has a slight advantage here as once deployed to the server location it is live. The thick client device must synchronise to download the latest application. This in itself is negligible since the application is downloaded in the background while the current application is in use, or when the device is back in the cradle charging for the night.

The key question is: As time and costs increase supporting Smartphone devices each time the business applications change, is the initial saving worthwhile as future development wipe-out any short term benefits?

Learn more about the options you have with Cloud solutions Vs Thick Client Platform as part of the mobile application development phase of your enterprise mobility project contact us today.

Subscribe in a reader
Or by Email

Explained Mobile Device Screen Types

Explained: Mobile Device Screen Types

Which screen type is right for your application?

With so many products in the market it can be quite confusing which mobile device screen types to choose from. This blog will cover in plain English the different types available in today’s enterprise mobility and consumer market.

Nearly all mobile devices allow touch, many can also sense a stylus or a pen. Some screens allow two touch zooming in and out, some are super bright, others have a very high resolution screen, or are rugged for impact protection.

The most common two technologies are resistive and capacitive. Resistive allows for both touch and stylus/pen contact. The screen comprises of two layers of which one has an electrical current. When the screen is pressed the layers meet and the X/Y location can be determined.  Resistive screens can be damaged if sharp objects can are used, but can also be easily cleaned and resistant to liquid damage.

Resistive technology can be found on almost all enterprise handhelds where to user may require either option, using the stylus when a very accurate screen location is needed or when using gloves.

Capacitive screens allow only touch. This is found on most Android, iOS Smartphones. These screens work with the human body to act as a current. The screen has an electrical current layer, when the finger touches the screen this creates a change in the current therefore fixing the location. One problem is use in cold weather as gloves cannot be used nor a stylus. Most capacitive screens do allow for two touch zooming in and out.

The next part to consider is the screen resolution. Displays are available in QVGA, VGA, XGA, WXGA, AMOLED, Super AMOLED etc. There are lots more. They all provide different resolution figures generally with the higher being sharper and clearer. VGA stands for Video Graphics Array, The X is for Extended, W for Wide, and S for Super. HD is high definition found on most TV sets. The figures are explained:

QVGA: 320 x 240
VGA: 640 x 480
WVGA: 800 x 480
WSVGA: 1024 x 600
XGA: 1024 x 768
WXGA: 1280 x 720 – 1366 x 768
HD: 1280 x 720

More reading!

High resolution devices will reduce battery life, but since higher resolution screens are found on Tablets and Laptops this is negated as they have much larger batteries than found on Handhelds.

Mobile application development design is also an important consideration as the layout needs to be sized to meet the resolution and text enlarged where appropriate. If you have a pool of various devices this could mean the application will look too small or large compared to the device the app was originally designed for. If you have a very basic small application a low resolution will be fine running on a PDA/Smartphone. If you have a complex large application and need more data the  various mobile screen device types may lead you to a screen with a higher resolution such as found on a rugged tablet pc.

Interested in learning more about using touch screen technology for your enterprise mobile project. Get in touch or evaluate a unit free for 10 days.

Cloud Solution Vs Thick Client – Devices

Cloud Solution Vs Thick Client – Devices

10" Rugged Laptop at work
Choose the right device for the application Algiz XRW notebook

When looking to move away from outdated paper forms to a mobile application businesses have two options; choose a cloud solution Vs thick client based solution. Choosing the device should be the easier part !

Many people new to mobile applications often consider using the latest iOS Smartphone or Android tablet  as they look stylish, the workforce wants a new phone and they are cheap when compared to other devices. Taken in isolation 9 times out of 10 this has been proven to be a costly error, why? because the mobile application development should fit the business need before selecting the device. Choosing the wrong device is expensive creates issues for the users and does not leverage the investment made against the application. It can also make a nonsense of any total cost of ownership projections.

The application needs to be defined –What data needs to be captured i.e. scan barcodes, RFID, capture GPS, capture signature, how much text? How long will the application be in use for each day? What environment is the device used in? How big will these screens be? How many pages will the application span over? Will other software be required to run?

If a signature is required the device criteria is quickly narrowed down removing a vast percentage of Smartphone devices that are touch only screens. Adding barcode scanning and/or RFID can be done with Smartphone devices and a handheld scanner, but for ease of use a rugged handheld would be the recommended option with a scanner built in. If the application is used throughout the day power consumption will be high so you may need extended batteries and a stable method of charging the device when on the move.

The environment needs to be factored in if the device should be rugged to avoid damage when knocked or dropped? Does it need to be protected from heavy rain showers or continuous bright sunlight? Could the user be wearing gloves or have dirty hands needing a stylus or keyboard? And is the device used indoors or outdoors? Screen brightness for good readability changes from device to device.

Another high priority is the screen size. Larger screens means less pages, quicker form completion and increased application overview. The trade off is size Vs ease of use.

Other factors are what other applications need to run on the device and the level of warranty required. If users need desktop software in the field the quick solution would be to look at Windows 7 Rugged Tablets. A one year limited warranty on a smartphones Vs a 3 year fully inclusive maintenance agreement  on a Rugged Tablet PC could mean that in a typical deployment a project could be acquiring Smartphones 2 or 3 times over.

When considering a Cloud Solution Vs Thick Client – Devices. The key question is: If a device doesn’t have the correct features to fit the business needs then why consider it for short-term savings? Buy the correct device once or buy the wrong device several times over?

 

Enterprise Mobile Apps Device Ports Features and Accessories

Enterprise Mobile Apps Device Ports features and accessories

T7200 Twin Battery Charger
Multiple Battery Chargers are Very Practical

As part of your project it is important to make sure your enterprise mobile apps device ports features and accessories are all set to support your investment in apps software.

For example if the software contains GPS tracking then the obvious solution is to purchase a mobile device with GPS built in. The same goes for scanning barcodes signing on screen or reading file from a USB stick.

GPS is a feature commonly used for in vehicle Sat Nav. It is also a feature used in GPS tracking systems and in specific software such as utilities to check location on pipes, cables etc. In the last case the GPS needs to be very accurate so compatible with WAAS/EGNOS.

Will the device ever need to read from a removable data source are PDF maintenance plans or boiler manuals required? The device must therefore have a way of reading from SD card or USB sticks. If the documents are full A4 documents containing a lot of text or images then the screen needs to be suitable size as well as the device running to software to run it such as Microsoft Office or Acrobat Reader.

Accessing data locally, leads to accessing data remotely; Does the device need a 3G connection to send/receive jobs throughout the day? Will the device be out of the office for days at a time so 3G is a definite requirement or will intermittent Wi-Fi suffice? Ethernet is another option for connecting to backend and online systems but usually only when in the office or working from home or hotel.

Saving the data locally once having accessed it is the next step. Is a specific manual required when at the customer site and will there be a 3G or Wi-Fi connection? In most cases the user will want to download the document to the device. Tablet hard drives can range up to 128GB, enough for almost all requirements.

Those are the basic features handheld and tablets can be supplied with. Additional features can include 1D and 2D barcodes scanners, RFID scanner and serial ports.

Once the device features have been decided the accessories are then an option. If the devices needs charging in the office or in a vehicle a variety of docks are available from a 4 slot multi-docks charging 4 units are once to a vehicle cradle wired directly into the vehicle power supply. Other more basic accessories can be carry cases, and spares such as stylus’s and screen protectors. All of which help to protect your investment.

The key question is: With so many cheaper, but limited Smartphones on the market should your business look at what features they require in a device or what will be a tolerable device for the least amount of money?

Enterprise Mobile Applications Screen Size and Keyboard

Enterprise Mobile Applications Screen Size and Keyboard

X3 PDA with mobile application
Nautiz-X3 Rugged Handheld with Integral Keyboard

The complexity and nature of a mobile application can often dictate the physical size and type of the mobile device you buy. The enterprise mobile applications screen size and keyboard input method is an important element of your total cost of ownership calculations

Consider the environment the device will be used in. What is the likelihood a device is accidentally knocked or dropped? A rugged device will long out last a Smartphone if it is dropped more than once.  Will the device be used indoor or outdoor? The perceived brightness of a screen can change from device to device and a high brightness screen will make outdoor readability much clearer. Other environment factors include if the user will be wearing gloves in which case a stylus or keyboard may be required.

Keyboards are an important choice frequently over looked if the mobile application requires any text input. A Smartphone onscreen keyboard is usually touch only and they can sometimes be very fiddly. Touch only is no good if the operator has dirty fingers or wears gloves. The next step up is a stylus on a PDA. The on screen ‘soft’ keyboard can be a bit difficult to use due to it’s small size. Rugged PDAs like the Motorola MC65 or Handheld Nautiz X3 come as standard with either a QWERTY or numeric keyboard. These are quick and easy to use. If the application only requires numerical input this numerical keyboard will save valuable time from switching to alpha characters.

Moving towards a full keyboard the on screen “soft” keyboard on our own T7000 Windows 7 Tablet is both quick and easy to use with finger or stylus, and also comes with a handy numeric keyboard built in. Other options at the full size keyboard level are to use a snap-on keyboard, connect a USB keyboard or consider a rugged laptop like the Handheld XRW with full size keyboard.

Another high priority is the screen size. A tablet screen of 7” will be able to display much more than a  2.8” Smartphone or PDA or rugged handheld screen. The application experience is enhanced by having more information on screen at any one time and fewer screens means quicker app completion. Other advantages also include the ability to increase text size for poor sighted users and display full screen images, PDFs and documents. But putting this is a pocket may be difficult hence the continuing attraction of phone size devices. Although a few years old this is still a great guide.

If additional requirements include the use of other software such as MS Office, mapping software service manuals PDF guides then a larger screen would be paramount.

The key question is: How the application will look and feel to the mobile worker should put screen and keyboard considerations at the top of your list of hardware requirements?

To find out more about how we can help you with pondering these issues please get in touch sales@mobileworxs.com or call 44 1905 799555

Windows 8 in the Mobile Enterprise

Windows 8 release – Impact On the Mobile Enterprise

Windows is Windows right!? Each version has had some level of backwards compatibility so you can run an app built for XP on Vista or 7, or in the mobile enterprise Windows Mobile 5 on 6.5, give or take a few tweaks depending how the application was designed. Windows 8 will be the same?

Microsoft Windows 8At the moment it’s difficult to know exactly how Windows 8 will perform, especially when looking at the mobile market for WOA (Windows on ARM), which is mobile devices running Windows 8 on ARM processors. This is because the hardware isn’t available yet. Manufacturers are hard at work creating hardware from scratch up just for WOA.

The devices themselves will share a wide amount of commonality with the full Windows 8 Desktop OS, bridging the gap between the two, but with the aim of the best of both worlds. That is combining the reduced footprint of Mobile with the features of a desktop OS. But the issue here is there will be no third party desktop applications. Applications have to go through the store, which become Metro (design language Windows 8 is based upon).

Rugged PDAs running Windows Mobile 6.5 may have to stay on Windows Mobile 6.5 for a while longer. Embedded versions of Windows Phone 7/8 are in the Microsoft road map later in the year but with no release dates the Mobile Enterprise market may have to wait. Not confirmed, but Windows may move away from the Compact Framework in the next release. Until Microsoft do confirm this there is little point worrying about it, but if they do it may mean challenges for a huge host of major players in the Mobile Enterprise.

Looking more at the Windows 8 platform as a whole, it is a cross device platform all linked via a Windows Live account. This means your “Live” content should be accessible from any Windows 8 device. Keeping the same OS layout over multiple devices will mean overall ease of use when switches between form factor.

Windows 8 32-bit & 64-bit based offerings on Intel/AMD will be released around October. Intel are currently working on optimising their processors to work with Windows 8 tablet machines.

Applications that were previously installed on Windows 7 can be installed in Windows 8 using the desktop – There are two types of GUI, the metro style block apps and the standard Windows Desktop. If already using Windows 7, a jump to Windows 8 shouldn’t be too much of a struggle. It should be an improvement.

At the moment it seems the Mobile Enterprise won’t be affected until the new release of Windows Mobile is launched. Microsoft’s goal appears to be taking some of the tablet market Apple & Samsung have dominated.

The key question is: As Android starts to become a consideration in the Enterprise market, is it worth waiting to see what Microsoft come out with and stay on Windows Mobile 6.5?