Bett was held at the Custom House in London Excel this year and was a veritable feast of the great and the good. With over 35,000 attendees expected I spoke to people from many parts of the world.  The DLR was so overloaded with people attending that at one point the service was stopped at Canning Station and everyone had to walk to Custom House.

With all the news coverage about how vital it is for teenage students to learn how to code, I was surprised by the lack of relevant coding platforms at Bett 2013.  This year the show seemed to be very well patronised by data and analytics – gathering data, measuring data and reporting on data.  Whilst that is all good and well, how are teenagers going to learn to code?  The app market continues to prosper, students are tech savvy, have increasingly sophisticated technology in their pockets and the importance of knowing how to code has never been greater. 

It must surely be both a challenging and rewarding time to be a teacher.  Today old school meets new school in the classroom and the potential for amazing results is just waiting to happen.  All that is needed is some creative thinking from the top down as well as the bottom up and the ability to let go of the past and embrace the new. 

Stephen Heppell, was inspirational with his approach to new ways of learning.  Stephen’s approach is to teach students how to learn then trust them to determine what works best for them in terms of classroom environment and use of technology.  It was great to see the ease with which lots of youngsters used Scratch on his stand at Bett.  Coding is close to Stephens’s heart and when LiveCode’s ancestor, HyperCard, came to market in the late 80’s Stephen created a HyperCard stack with which it was launched.  Stephen is a breath of fresh air in the Digital World of learning and his approach has a proven track record of success. 

Dell had a Formula 1 racing car on their stand sitting next to a racing simulator which was hugely
popular.  The new Windows 8 Dell Tablet is ideal for using apps build on LiveCode by students and many students and teachers who tried it out for themselves, thought so too. 

Everyone fell in love with the very human Nao Android Robot it will be interesting to watch how this evolves to be used as a teaching tool.  The Active Robots folk were keen to try out LiveCode to see if it could drive the Nao so watch this space it may just happen

Looking forward to Bett 2014!

 

read more

by Mark Smith

Mark Smith manages the data repository at the Manitoba Centre for Health Policy and conducts health research.  In his spare time he codes medical and other kinds of applications using LiveCode.    

______________________________________________________________________________________________

If you have sensitive information that needs to be secured on an iOS platform then you may find the following discussion useful.  Such was the case for a hospital application I was developing that required the collection of personal health information.  Not surprisingly the client was only willing to consider a mobile option if the information could be securely stored and managed on the device as well as off.  And, unfortunately, storage on the device was the only option since the hospital had neither 3G nor wireless available (which would have allowed a mobile client/server solution).

Securing data on iOS is not as easy as it sounds.  If you provide no more protection than a simple 4-digit numeric passcode, then this can easily be defeated.  There are desktop applications that can be downloaded that can brute-force discover any 4-digit numeric code in under 20 minutes.  Things get a little better if you use a more complex passcode and you can enforce the requirement of a complex passcode by creating a configuration profile for your device (more on that in a bit).

So I was really pleased to see that RunRev had implemented support for the hardware based encryption that is built into iOS through the Data Protection API in version 5.5 of Livecode.  As noted in the LiveCode documentation, there are four options available for the iphoneSetFileDataProtection command:

• none – No protection
• complete – The file is not accessible, for reading or writing, while the device is locked.
• complete unless open – The file is fully protected when the device is locked, unless it was already open.
• complete until first user authentication – The file is fully protected until the user unlocks the device for the first time.

You should also be aware that this additional level of security is enabled by having a user passcode installed on the device.  No passcode, no protection.  That is the critical first step in enabling all of the above options.  Also, the documentation leaves lots of questions as to what state a file will be in during the course of its life, and certainly what state it will be in when it leaves the device.  To answer some of these questions I constructed a few tests.  You may find the results surprising.

To begin with I created an SQlite database file and added a few records.  I set the file protection level on this file to “complete” and then I locked the device. 

Next I used Xcode to transfer the file to my desktop. I was expecting to see an encrypted file but was surprised to see a blank one.  Well, from a security perspective blank is good.  No brute force attempts to decrypt it are possible. (Note: I have gotten different results using different versions of Xcode.  Some return no file at all when the file is protected and the device is locked).

Then I unlocked the device and again transferred the file using Xcode, and as the documentation suggests, this file was completely readable. This is fine if you think no one can spy on your device while it’s unlocked, but what happens if the file is inadvertently backed up to iTunes or iCloud while the device is unlocked?  Is the file protected in that case? 

Well, in the case of iTunes the answer is “No”.  The file is completely readable regardless of whether the device is locked or unlocked when the backup is made.  Now, I was expecting the file to be readable when backed up from an unlocked device, but I was not expecting it to be readable when backed up from a locked device as well.

I suspect what is going on is that Apple treats a backup to a known trustworthy device the same as unlocking the device.  You may recall when you first attempted to backup your device Apple asked you to enter the passcode.  It probably stored it somewhere, and whenever the file is backed up again it uses that copy to decrypt the backup files.

In the case of backing up to iCloud, the Apple documentation says that all files backed up to iCloud are encrypted but my understanding is that the encryption is done with keys that are stored on the server side, so there is still a very small risk that someone hacking into Apple’s servers could discover both the keys and the files.  However, given the sheer volume of backups that Apple maintains, there is some protection from the anonymity of being in such a large crowd.

So what have we learned?  First, the iphoneSetFileDataProtection “complete” option appears to work to encrypt and secure the file when it is not being accessed.  It is likely that the file is adequately protected until an authorized user (one who knows your passcode) requests access to the file.  Second, it is not protected at all when backed up to iTunes.  If that situation concerns you (or you don’t want the file backed up to iCloud), you have several options:

• Set the don’t backup flag on the file
• Put the file in a location that iTunes won’t back up
• Set iTunes to create encrypted backups (this is the only option for iCloud)
• Turn off iCloud backups
• Encrypt the file yourself

To set the file so it won’t be backed up use the iphoneSetDoNotBackupFile command with thedoNotBackup Boolean option (where true = do not backup):

To put the file in a location that iTunes won’t back up use either the /Library/Caches directory or the /Library/tmp directory.  However, both of these locations can have files periodically removed by iOS to free up space, so they do not provide a solution for long term storage.  The Apple recommended strategy is to mark the files as “do not backup”.

To create encrypted backups using iTunes, select the devices tab in iTunes and select your device. Then check the “Encrypt local backup option”.  While you are there, you can also turn off iCloud backups by unchecking the “iCloud” option.  Also, on your iOS device, using the “Settings” app you can disable iCloud backups under the iCloud/Storage and Backup option.

Of course there are other options as well.  One is offered by Monte Goulding with his mergAES external for Livecode.  I bought a copy of this to try out and I must say it has worked remarkably well for encrypting and decrypting the file on the fly on the iPad as well as ensuring that once the file leaves the iPad it remains encrypted (an added bonus frankly!).  There is also an option in mergAES to encrypt the file in a format that is compatible with Livecode’s decryption routines (you need to use the OpenSSL format in mergAES).

Click image to zoom

Just don’t expect iphoneSetFileDataProtection to solve all of your security concerns unless you are only interested in protecting your files while they are “at rest” and you use a complex password on the device.  If you really want the data to be secure you will probably have to double encrypt the file using something like mergAES.  That way, if someone is really determined to get at your data they will find that after circumventing the first hurdle (your passcode) they are still left with a securely encrypted file.

Of course there is lots more to iOS file and application security than what I’ve covered here. Recently I ran across a new publication by Apple that appears to cover the iOS security issues in much more detail than has previously been reported (it’s 20 pages in length).  As of Dec 8th, 2012 you could find the document here.

(NOTE: as of January 4, 2013 this document is no longer available or is encrypted. If anyone wants a copy please request in the comment box below).

Finally, if you are handing out iOS devices, you may want to consider enforcing the use of a complex passcode as well as other security settings.  You can do this by creating a configuration profile for the device.  I don’t have the space here to go into this in any detail but luckily Apple has a tool you can use (the iPhone Configuration Utility) that will work on any iOS device and it has excellent documentation. 

Click image to zoom

The Configuration Utility is available here.

The only solution I can think of that would be better is to have encryption built right in to the SQlite library (there is such a package, but it is not licensed by Runrev.  If you think you would use this you might want to send RunRev a note sometime to let them know).  Well, that’s it for me.  As you travel down your “mobile” path in life may your data always be secure.

read more

By Dharmesh Shah at Hubspot

If you’re like me, you probably use Google many times a day.  But, chances are, unless you are a technology geek, you probably still use Google in its simplest form.  If your current use of Google is limited to typing a few words in, and changing your query until you find what you’re looking for, then I’m here to tell you that there’s a better way – and it’s not hard to learn.  On the other hand, if you are a technology geek, and can use Google like the best of them already, then I suggest you bookmark this article of Google search tips.  You’ll then have the tips on hand when you are ready to pull your hair out in frustration when watching a neophyte repeatedly type in basic queries in a desperate attempt to find something.

By learning and using the 12 tips below, you’ll rank up there with the best of the Google experts out there.  I’ve kept the descriptions of the search tips intentionally terse as you’re likely to grasp most of these simply by looking at the example from Google anyways.

12 Expert Google Search Tips

1. Explicit Phrase:
   Lets say you are looking for content about internet marketing.  Instead of just typing internet marketing into the Google search box, you will likely be better off searching explicitly for the phrase.  To do this, simply enclose the search phrase within double quotes.
   

   Example: “internet marketing”

2. Exclude Words:
   Lets say you want to search for content about internet marketing, but you want to exclude any results that contain the term advertising.  To do this, simply use the “-” sign in front of the word you want to exclude.
   

   Example Search: internet marketing -advertising

3. Site Specific Search:
   Often, you want to search a specific website for content that matches a certain phrase.  Even if the site doesn’t support a built-in search feature, you can use Google to search the site for your term. Simply use the “site:somesite.com” modifier.
   

   Example: “internet marketing” site:www.smallbusinesshub.com

4. Similar Words and Synonyms:
   Let’s say you want to include a word in your search, but want to include results that contain similar words or synonyms.  To do this, use the “~” in front of the word.
   

   Example: “internet marketing” ~professional

5. Specific Document Types:
   If you’re looking to find results that are of a specific type, you can use the modifier “filetype:”.  For example, you might want to find only PowerPoint presentations related to internet marketing.
   

   Example: “internet marketing” filetype:ppt

6. This OR That:
   By default, when you do a search, Google will include all the terms specified in the search.  If you are looking for any one of one or more terms to match, then you can use the OR operator.  (Note: The OR has to be capitalized).
   

   Example: internet marketing OR advertising

7. Phone Listing:
   Let’s say someone calls you on your mobile number and you don’t know who it is.  If all you have is a phone number, you can look it up on Google using the phonebook feature.
   

   Example: phonebook:617-555-1212 (note: the provided number does not work – you’ll have to use a real number to get any results).

8. Area Code Lookup:
   If all you need to do is to look-up the area code for a phone number, just enter the 3-digit area code and Google will tell you where it’s from.
   

   Example: 617

9. Numeric Ranges:
   This is a rarely used, but highly useful tip.  Let’s say you want to find results that contain any of a range of numbers.  You can do this by using the X..Y modifier (in case this is hard to read, what’s between the X and Y are two periods.)  This type of search is useful for years (as shown below), prices, or anywhere where you want to provide a series of numbers.
   

   Example: president 1940..1950

10. Stock (Ticker Symbol):
    Just enter a valid ticker symbol as your search term and Google will give you the current financials and a quick thumb-nail chart for the stock.
    

    Example: GOOG

11. Calculator:
    The next time you need to do a quick calculation, instead of bringing up the Calculator applet, you can just type your expression in to Google.
    

    Example: 48512 * 1.02

12. Word Definitions:
    If you need to quickly look up the definition of a word or phrase, simply use the “define:” command.
    

    Example: define:plethora 

Hope this list of Google search tips proves useful in your future Google searches.  If there are any of your favorite Google expert power tips that I’ve missed, please feel free to share them in the comments.

read more

By Heather Laine

A recent newsletter article in revUp got me thinking about this topic.  It seems extraordinary that already, in just 20 or 30 years, we can be using the word archaeology in connection with computing and IT technology. Surely it’s too soon? We all know what a floppy disc is, don’t we? We remember those 128k Desktop Computers that required a reinforced desk to put them on and a second mortgage to purchase them? I don’t know about you, but I’m certainly not a dinosaur yet!

And yet…

There is a beautiful mountain walk near where I live, up a valley which used to be a big industrial site.  You’d never think it now, until you reach the end of the path, and you see a tall factory chimney rising out of a quiet sheep covered moorland.  Nearby are some old workings and a tourist board notice.  The board dates the workings to the late 1800s.  It says, “It is thought the chimney was associated with ventilation for the mine…” What?  This is only a hundred or so years ago, and we don’t know what it was for?  I guess everybody thought Tom was writing it down…

Around the world there are millions of floppy discs and even older media quietly rotting in landfill sites, cellars, attics and forgotten cupboards.  I have a bunch of them myself, and I certainly no longer have any kind of computer that could run them.  That data is gone as far as I am concerned.  Hope it wasn’t important!

There is a vast store of data out there, on somewhat perishable media, and within a few years there will be virtually no machines left capable of reading it.  Most of it undoubtedly is dross but there must be a huge body of work worth saving.

With the advent of Mobile, many games that were written for what today are regarded as extremely low spec machines have a new venue.  Mobile devices need games that pay some attention to size and speed, offering a home to those much loved games you played way back when 128k was a lot of memory.

Perhaps even more transient and in need of preservation are historic and ground breaking websites.  Do you remember your first web browsing experience?  Come a long way since then, haven’t we!  I vividly remember the hamster dance, possibly one of the earliest internet memes.  I was mesmerised – I’d never seen anything like it.  It was a big step along the road to making websites move and sing, and it would be a huge shame if the youth of today could not experience the joy of 4 repeating hamsters cycling through 4 gif images to a sped up Disney tune!  When I came to hunt for the link for this article however, it was not easy to find anything resembling the original.  

The hamsterdance.com site is now a sleek modern version with merchandise galore (and to my mind totally lacking the charm of the original).  The link I did find for you is a reconstruction.  Unlike books, websites leave no physical trace when they are overwritten or erased, and unless consideration is given now to preserving and recording the history of the internet, much will be completely lost.

Do we care?  Should we care?  Obviously we cannot and probably should not attempt to preserve everything.  But if in 50 years’ time little Johnny in his digital immersion world holotexts his grandma to ask “How did the internet get the way it is today?” I think it would be a good thing to be able to answer that question.

 

read more

By Heather Laine

They say that if you want to write compelling content, write about what you know.  Having worked in Customer Service for RunRev for over a decade, I think I can safely approach this topic.  

Of course, none of us are perfect and only a robot could give perfect customer service every time… except nobody likes a robot.  This is an accumulation of the things I have learned by trial and error over the last 10 or so years.

It’s probably worth starting by defining what, in my opinion, constitutes good customer service. I’d say that to be truly successful, your customer should go away from any contact with a feeling that they have been listened to, and their question(s) have been answered, quickly, accurately and politely.  In an ideal world, you would also always be able to give him/her whatever it was they wanted, but if that is not possible they should understand and hopefully accept why it is not possible.

Anticipate
Truly excellent customer service involves answering your customers’ questions before they even ask.  Provide information on your website, keep your FAQ updated and send out informational emails for example if you have a new release your customers want to know about.

If something goes wrong, write or call your customer and tell them, before they call you.  They may not be thrilled to hear that their delivery is going to take a month because the shipper’s grandmother has suddenly expired and he’s spending three weeks in Brazil at her funeral, but they would rather hear it from you, now, than write to you in three weeks time when they have become incandescent about the non-delivery.

Listen
Carefully.  This is key.  Do you really understand what the customer is asking? Read their email twice, and if it’s a phone call, ask them to repeat or explain anything that got past you the first time.  There is nothing more infuriating than receiving an off the shelf answer to a question which completely misses the point.  If you don’t understand, ask, but first make sure you have really tried to comprehend from the information you already have.  Asking for information that was already in the original email does not make the customer look kindly on you.  If you are not sure you understood correctly, reiterate what you think they meant and ask if this is correct.

Check
Never assume.  If you receive a report from a customer that your software is doing something strange and (clearly) impossible, start from the position that they may be right.  Try it yourself before you tell him or her that what they are experiencing is impossible.  You might just find that hey, if you press that button before this one, and then resize the window, a white rabbit DOES hop out on your desktop.

It’s probably worth starting by defining what, in my opinion, constitutes good customer service. I’d say that to be truly successful, your customer should go away from any contact with a feeling that they have been listened to, and their question(s) have been answered, quickly, accurately and politely.  In an ideal world, you would also always be able to give him/her whatever it was they wanted, but if that is not possible they should understand and hopefully accept why it is not possible.

There is a corollary to this one.  Whilst the customer is always right it is also possible that what they tell you is incorrect.  They may have the firmly held belief that they have a license for version x, but in fact it may be version y.  The date that they purchased might not be accurate.  The name or address or email they purchased with could be different.  Check everything.  If you know that the problem as described cannot be happening, checking the details may provide the answer.

Be Polite
This seems obvious, but it’s astonishing how often providers of customer service forget this one. Yes, you may have had a long day.  You may be tired and you may be receiving the same question for the hundredth time (in which case, you should update the FAQs on your website). The customer on the other end of the phone may be unreasonable, awkward or downright rude. The email you just received may demonstrate that the person sending it has neither read the instructions (who ever reads the manual?), nor your last carefully crafted email and they have just done the exact opposite of what they were supposed to, thus creating an hours’ worth of work for you to fix it.

None of this excuses rudeness in your response.  If the missive you have received is truly inflammatory and you simply cannot bring yourself to reply politely, either pass it to a colleague, or wait 24 hours before responding.  Remember that customers are human beings, just like you, and maybe they had a bad day too.  Perhaps the dog bit them, they lost their job or their wife just left with the kids and all the cash.  A polite reply and an offer to assist with the issue they are shouting about may bring an apology in the morning – and if it doesn’t, let it go.  Your job is to solve problems, not start wars.

Re-read everything you write carefully before you send it, and check that the tone has come over correctly.  Email can be a tricky medium, and something you write perfectly innocently may come over in a way you did not intend.  It’s useful to remember to use neutral language as a matter of course.  For example this statement:

I’m sorry to hear about your problem with x, you need to do y…

is not neutral.  It implies that the problem is not yours, it is theirs, and suggests blame.  Instead:

I’m sorry to hear about the problem you are experiencing, here’s how it can be solved…

is a better way to write the same thing.

Be honest
If a customer asks you for something you cannot deliver, say so.  Be realistic about what they can achieve with your product, and make sure you set their expectations correctly.  It’s better to under promise and over deliver than to make a sale based on something you cannot provide.  If the average turnaround time for an email response is 2 days, and you promise a response within 24 hours, you will end up with an unhappy customer.  If you say 2 days, and then reply within 24 hours, your customer is surprised and delighted.

Build Relationships
Finding ways to relate to people is a huge element of customer service.  A little chit chat about the weather, the political situation, or topics of common interest is not a waste of time.  It is an acknowledgement that the person you are talking to is in fact a person, not a problem.  It builds trust and mutual respect, and over time ensures that your customers remain your customers. Obviously, you need to put limits on this.  You are providing support for a company, not a counselling service. Some customers are simply lonely and looking for human contact, and if you respond too much you will end up spending hours reading and writing long essays that have nothing to do with your job.

Don’t Pass the Buck
The customer asked You that question. Not the guy across the room, or in another department. If you don’t know the answer, find out. Go the extra mile. You may actually be getting the answers from someone else (Google is a wonderful invention!), and simply passing them on, but nobody likes to be passed around from pillar to post.  If you really need to pass the whole issue on to someone else, tell the customer you will follow up on it if they do not receive the help they are looking for.  And do it.

If queries for another department regularly end up on your desk, you need to fix your sorting system.

As a side note… I have a personal and passionate hatred of telephone systems where you press 1 to speak to sales, press 2 to speak to support… and a new and hideous evolution of this, where *all the responses are automated*.  There are systems now for big and supposedly reputable companies where it is actually impossible to talk to a human.  Heaven help you if your query is non-standard and cannot be answered by a canned response!  I am proud of the fact that if you call RunRev, you will be answered by a real live human, who will either answer your query themselves or direct your call appropriately to another real live human.

  Get me a human!

Become Clairvoyant

This really helps… Anyone working in support will tell you that the query they most hate to receive is

“your product doesn’t work, help!”

Which product, exactly?  When you say “doesn’t work” do you mean you were unable to download it, install it, or unlock it?  Or perhaps you achieved all of the above but it quits on opening?

Generally, you will have to write back to the customer and ask all of the above, but sometimes you can amaze and astonish by deducing the problem.

I’m not really clairvoyant, I just receive an awful lot of queries that resemble each other. If a certain issue comes up time and again, it may well be that issue that is causing the trouble. If it looks like a duck, and quacks like a duck, it may be a duck and its worth asking the customer “have you tried so and so, does this solve the problem?”. But you need to be careful with this approach, because sometimes it turns out to be an armadillo. Whilst offering the solution, also remember to ask for all the information you will need to solve the problem if you guessed wrong.

Sometimes, the question the customer is asking is the wrong question. What you need to provide in this situation is the right answer to the question they didn’t ask. Remember that in the end what you are looking to provide is a solution to the problem, rather than an answer to the question. For example, you could be asked “How can I send a payment to you via Paypal”. The literal answer might be “You can’t, we don’t take Paypal” (you should, of course, and you’ll need to have a chat to your engineers about that). But the problem to solve here is really “how can I buy your product”. The correct answer would be “You can pay us over the phone using a card, or by wire transfer to our bank, here are our bank details, and if you have any difficulty please let us know and we’ll see how else we can take the payment”.

All of the above really can be summed up by the mantra: give the service you would like to receive. If you were the customer, what response would you be looking for?

I’m not really clairvoyant, I just have received an awful lot of queries that resemble each other.  If a certain issue comes up time and again, it may well be that issue that is causing the trouble.  If it looks like a duck, and quacks like a duck, it may be a duck and its worth asking the customer “have you tried so and so, does this solve the problem?”.  But you need to be careful with this approach, because sometimes it turns out to be an armadillo.  Whilst offering the solution, also remember to ask for all the information you will need to solve the problem if you guessed wrong.

Sometimes, the question the customer is asking is the wrong question.  What you need to provide in this situation is the right answer to the question they didn’t ask.  Remember that in the end what you are looking to provide is a solution to the problem, rather than an answer to the question. For example, you could be asked “How can I send a payment to you via Paypal”.  The literal answer might be “You can’t, we don’t take Paypal”.  But the problem to solve here is really “how can I buy your product”.  The correct answer would be “You can pay us over the phone using a card, or by wire transfer to our bank, here are our bank details, and if you have any difficulty please let us know and we’ll see how else we can take the payment”.

All of the above really can be summed up by the mantra: give the service you would like to receive.  If you were the customer, what response would you be looking for? 

read more

Mobile Apps are becoming a major delivery vehicle for health services of all kinds.

By Heather Laine

There’s a new jargon term in town: mHealth.  The health sector is a huge growth area for mobile apps.

When you think about it, this makes sense, in so many areas.  A mobile phone is the perfect place to deliver an app that helps you monitor what you eat, how you exercise, when you take medication or even keep tabs on your heart-rate.  The benefit of instant availability from your pocket or handbag is clear.  You can look up the calories in that delicious chocolate cake the restaurant is trying to tempt you with.  (Chocolate of course is good for you, its practically a vitamin so you should eat the cake anyway).  You can feel a glow of virtue when you complete the training regimen for the day set by your cyber trainer.  There is a huge and growing range of lifestyle apps on the market, designed to make us look, feel, and live better.

But mHealth is not just a boon for you and I, with lifestyle apps offering maximum convenience to maintain that diet or count the number of steps we took today.  It’s potentially a huge efficiency saving for health services, and can improve the quality of life for many sufferers of chronic illness or old age.

Apps can monitor a patients’ heart beat in day to day situations, rather than in the artificial surroundings of a clinic (does your heart rate go up when you’re waiting for your doctor to diagnose the problem?).  Diabetics can benefit from on the spot blood sugar readings.  The elderly can carry a built in alarm at all times to summon help in the event of a fall.

There are other ways in which mobile health provision can cut costs and improve care.  Skype consultations with your doctor may become the norm.  Why sit for an hour in a waiting room, catching flu from the toddler who is tripping over your legs, when you could stay home and talk it over in comfort?  Mobile provision of health care is already offering a lifeline to remote communities, with the possibility of snapshotting and uploading descriptions of illness or injury, and receiving advice from the Cloud on the best way of treating the problem.  Mobile health provision is likely to become mainstream for many purposes in both the developed and developing world.

Doctors also benefit from fast and easy access to data and records.  Instead of rummaging through archaic filing cabinets, which may be situated in a hospital many miles from the care providers’ actual location, a quick query from a cell phone app can provide the required information.

Young people make up the biggest percentage of health app consumers.  This is probably because the younger generation is no longer able to get out of bed without the help of their mobile phones.  Lifestyle apps are probably the biggest area of interest for this group.  Cell phone uptake in the older generation still lags behind, but this group is likely to be a strong growth area for mHealth apps, given the huge benefits mobile technology can deliver to the elderly.

It’s not hard to see why health is a growth sector for mobile apps of all kinds.  And LiveCode developers are already getting a slice of the action.  Check out HIV for Your Heart, an all encompassing app assisting HIV sufferers to remain well and lead healthy lives, by Tim Bobo, or Tracker 2 Go, a diet monitoring program by Andy Henshaw.  Both of these are popular LiveCode built apps available to download in the Apple App store.  A number of our developers have created apps to help doctors handle their records – obviously, for confidentiality reasons these tend to be proprietory and not publically available.  If you have or are developing an app in the health sector, we’d love to hear from you!

read more

How far should you go to fight piracy? Is it even worth the effort? Just how much damage does piracy do?

by Heather Laine

A discussion on the use-livecode email list got me thinking about this hoary old topic again. Software piracy. Where are we at with it these days?  It’s an emotive topic that evokes anything from exhausted apathy to outright fury in a software developer.

Why is this such a huge problem?  What is it that allows normally honest, well-meaning people who would not dream of, say, stealing a sweater from a supermarket, or who would have no difficulty at least in understanding that stealing a sweater is theft, regard anything composed of bytes as rightfully theirs?  I guess its to do with tangibility.  Software is not a physical object, and humans seem to need to have something to actually hold in their hands before they regard it as “real”.  If it’s just pixels on a screen, how can it really have a cost associated?  All they have done is press a button, and the “object” they have downloaded still remains available online, for the next person to download, so how can they be stealing?

Then there are all those people who mean to pay.  Sometime.  Eventually.  When they get round to it and the price of bread is cheaper and … hey, wait, why did that software I’ve been using free for years suddenly flake out on me?? What do you mean, I never paid for it?

Of course, we, as developers, know that those pixels on a screen represent weeks, months, even years of work, during which time we have bills to pay, mouths to feed, and in a very real way software piracy is damaging our livelihoods.  Everytime a normally honest person downloads and uses our software without paying they are stealing from our paypackets.  I’ve had many conversations with people who say things like “oh, but look at the price of software!  Microsoft are making so much money its obscene, why should I pay for it?  Developers should sell their software cheaper, then we wouldn’t have to pirate it!”  Well, that may be true of Microsoft, but its certainly not true of Joe Developer, just trying to make enough from his or her efforts to get by. And just as in the insurance industry, if everybody paid for it, the prices would come down dramatically.  All those good folks out there who do cough up for software are paying for the silent underbelly who are not.

Which brings me to the numbers.  Exactly how big a problem is piracy? Well, according to the 2011 BSA Global Software Piracy Study, piracy stands at 42% globally and rising, representing $63 billion in lost sales to the software industry.  If one makes some sweeping assumptions about what is being pirated and by whom, on average that could translate into software being almost 50% cheaper, if everyone paid for what they use.  Or, looking at it another way, you could be earning almost twice as much, and ploughing money back into new products and more innovation.

So what can we do?  It’s a truism that a determined enough hacker is going to pirate your software, whatever protection you put on it.  In some cases, the more intricate your protection, the more satisfaction a cracker will get out of pirating it.  This doesn’t mean we should throw up our hands in despair however.  There are things that can be done, to keep the honest people honest.  Granny Smith or Mrs Bloggs are not going to go to great lengths to circumvent your trial system, or break your keycodes.  You can even, if you are smart, turn casual piracy to your advantage.  If your software is good, and people love using it, then a free copy can eventually turn into a sale, maybe with an upgrade, or some kind of trace system where you can identify illegally used copies and contact the users. By and large however, for individual developers, spending their energy on combating piracy is counterproductive.  Our time is generally better spent on making the software worth paying for and marketing it so that its easier to find the paid versions than the free ones.  We just can’t afford to spend our time chasing rainbows.

Ultimately, the solution has to be a change in attitude and perceptions.  Public sympathy tends to be with the “Robin Hood” guys who are “stealing from the rich and giving to the poor”.  A story about the poor developer guy pushed out of business by the big, rich, software pirates… well, I haven’t seen one lately.  Have you?

read more

by Jacqueline Landman Gay

Jacqueline Landman Gay is the owner of HyperActive Software, a hypermedia programming company in Minneapolis, MN.  HyperActive Software produces quality commercial HyperCard, MetaCard, and LiveCode applications for corporate, educational, and private markets.

_______________________________________________________________________________________________ 

There is one single thing that defines a top-quality application: everything works.  This may sound simplistic, but it’s the bottom line.  It doesn’t matter how slick your user interface is, or how tricky the scripts are, or how sophisticated the material you are presenting; if everything in the project doesn’t work exactly right, your work will be ignored — or worse, scorned — by others.

There’s no secret to creating a great application that people will use and enjoy.  Test the application and everything in it, again and again.  Run everything through its paces several times and in different orders.  Click every button, read and scroll every field, run every script.  Show every dialog — and when you do, try every possible response button. Then get all your friends to do the same thing too.

That’s it.  Everything else I’m about to tell you is just commentary.

Most application errors and mistakes can be prevented by using a few simple testing techniques. Unfortunately, too many authors don’t want to take the time to test their work adequately.   While the fun may be in designing and scripting an application, remember that everyone else’s opinion of it will be based on its performance.  Users have high expectations of software these days, and they won’t take time to figure out work-arounds to glitches.  They’ll just toss your application in the trash instead.  Worse yet, they may avoid your work in the future based on one bad experience.

Try the following tips before releasing your application.  You may be surprised what you find. These techniques should ensure that your application is as bug-free as it can be.

1. Pretend you just met your application in a crowded library and you don’t know anything about it.  Start clicking on (or typing into) everything.  This doesn’t just mean using the obvious buttons; it means, for example, clicking on locked fields that have scripts, and using all dialog boxes.  

   Repeatedly bring up every dialog box until you have tried all possible responses to it, and don’t forget “cancel”, you need to account for a user wanting to bail out.  Don’t forget any buttons that are hidden on the card right now but that might be visible and used later; activate and use those buttons too.  Every button should do exactly as it is labeled (so choose your button names carefully).  

   Every script should interact cleanly with everything else in your stack, without causing any errors.Click outside any buttons or fields, right on the card itself, to be sure that nothing unexpected happens. If you’ve created any menus, systematically choose every single menu item, one at a time, to be sure it behaves right.
    

2. Set up some fake data with known content and test with that.  Say you
   have a stack that opens a text file of numbers and totals them.  Set up a text file and get a total with your hand calculator.  Then run your application on the file and see if you get the same results.  Or suppose you have a script that counts the number of times a text string occurs in another stack.  

   Set up the other stack with a known number of repetitions of some text and then see if your script returns the right number.  Too often scripters will suppose that if the script doesn’t error when it runs, it must be okay.  All that means is that you haven’t any syntax errors; it doesn’t say anything about the accuracy of the results when the script is done.  Do tests on several different sets of known data.  

   One set isn’t enough; you need to account for all types of variation.  In the first example above, you might create a text file containing all numbers except for one line of text.  What happens when you run your script on that?  
    

3. Once you’ve tried everything, and I mean everything, go back and try it all over again in a different order, preferably the wrong order.  This will be incredibly educational.  Don’t fool yourself into thinking that your users will click all the buttons in the correct order, or even in any logical order (although your stack must present everything in an orderly way). 

   For example, what happens if a user decides to push a “calculate” button before they enter any data into some number fields?  Does the app exit gracefully?  Or does it error out half finished and leave the stack in an unpredictable state?  What happens if users enter letters and other symbols that aren’t numbers, or type in numbers in the wrong range (always test-enter numerical data as negative numbers at least once).  

   What happens to your other scripts when one script fails? Do you get a cascading failure when each succeeding handler looks for information that now doesn’t exist, or exists in the wrong format?  Try your hardest to enter incorrect information into every field, enter data in the wrong format, and click every button out of logical order.  While it is fine if this doesn’t produce any usable results, it should definitely not produce any script errors either.  

   If it does, you haven’t done enough error-checking in your scripts. Don’t think to yourself, “my stack is aimed at Mensa members with IQ’s over 165 and they would never do that sort of thing, so I don’t have to check for it”.Trust me, they will.  And you do.  Whenever you repair a script, no matter how small the change, start the testing process over again.  

   There’s no way around it; you have to be sure not only that the change in your script works correctly, but that it works correctly with everything else.  You can use some judgment here.  If you alter a script that displays information in a field, you probably only have to test that one script to be sure the display is correct.  But if any other part of your application uses the data in that field later, then you need to re-test every other script that uses that field information. This may sound tedious, but it is the only way to avoid one of the main causes of errors: the interaction of different elements of your application.
    

4. Get three other people to run your application.  This is hugely important.  Never, ever release an application that no one else has used.  If you don’t know three other people, at least get one.  If you know more than three, go for as many as you can rope into it.  No two people will use your application the same way.  

   Certainly no one will use it exactly the way you think they will. What they do with your app will tell you worlds about your work. Choose people for testing who are as close as possible to the kinds of people who will be downloading and using your application.  If your app is for children, use children to test it. If it’s for anthropology professors, find some of those.  

   If you don’t know any anthropology professors then you can use your mother if you have to, but don’t expect her to find all the anthropology mistakes.  She will, however, probably still find a lot of generic errors having to do with application design. Don’t tell your testers what to do. This is a strict rule. Let them read any documentation or Read Me files you will upload with your application, but that’s all.  

   This is easier said than done, but remember that no one who downloads your software will have you around to give them verbal directions, and your tester shouldn’t get any either.  So limit yourself to watching, bite your tongue, and take a lot of notes.  See what actions they choose to do first, where they get stuck, and how they look around in the app for help if they need it (you did put some help info in there, right?).  

   This will tell you where your design isn’t clear. Don’t offer any advice unless the other person asks outright, and in that case give as little information as possible to get them back on track.  When they’re done, you can ask them questions from your notes if you need to.  Ask what they thought was good about the application and what was not so good.  

   Pay attention to what they say and change your app if necessary.  Try not to decide that they “didn’t know what they were doing” and don’t dismiss their comments as irrelevant.  If your testers can’t figure out your application, probably no one else can either.
    

5. Run your application on other people’s computers, the more the better. If you are distributing cross platform, you must test on as many variations of your target platforms as you can lay your hands on.  How do the fonts look? Does the text overspill your buttons? Is your card size too big to show up fully on a small laptop screen, or does it diminish to a postage stamp on a 27″ monitor?  How about speed?  Is it acceptable on other computers? What flows smoothly on your state-of-the-art computer may stutter or crawl to a halt on an older machine.
    
6. There’s one last way guaranteed to find every possible obscure bug, hiccup, and glitch in your application: demo the application to someone else.  No matter how much testing you’ve done or how many people have gone over your work, if there’s one obscure thing that can go wrong, it will gleefully manifest itself when you are trying to show your work to an important person — like a potential client, your latest love interest, or your anthropology professor.  

   Those tiny little bugs that have been lurking under the paint layer just drooling for a chance to embarrass you will burst suddenly on screen, grinning and winking at each other.  If you really, really want to find minute and obscure bugs, try showing off your software with as much pride as possible to someone important.
    

7. Avoid the “it’s my baby” syndrome.  It is tempting, after spending a lot of time with a stack, to want to leave it just as it is, simply because it’s your baby.  Be ruthless.  Even babies are better for a little discipline.  If something isn’t appropriate for your application’s purpose, take it out, no matter how cute it is or how much time you spent writing it.  

   If your testers complain that fourteen repetitions of The Hamster Dance are a bit excessive, take it to the trash no matter how cute you think it may be.  Remain constantly flexible.  You don’t have to change everything your testers say (after all, they really might NOT know what they’re doing), but you should sure listen closely when they say it.

If you follow these testing guidelines, you can produce software that is consistently bug-free and reliable.  The longer you test, the more people you test with, and the more repeatedly you test, the better your apps get.  Even the simplest application can become pure art when it runs smoothly, behaves intuitively, and functions without errors.

 

read more