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

by Jarren Harkema

Jarren Harkema is a home-schooled high school student who won his LiveCode license by entering a coding competition with RunRev. He is now sharing his passion for coding with his peers by mentoring The Sharks, a home-schooled FIRST LEGO League Team from Michigan.

——–

(This is Part 2 of Robotics, Research and Apps: Reporting from FIRST LEGO League.  Part 1 can be viewed here).

Loud speakers are playing Party Rock Anthem in a gym full of elementary and middle school students.  They wear brightly colored T-Shirts displaying fun team names, such as “The Fantastic Fourheads” and “The Sky Guys”.  Some are dancing around, cheering, or clutching their hair in anticipation.  The atmosphere is very energetic and tense.  The main event?  Three pairs of 4 by 8 foot plywood tables hold a brightly colored mat and are strewn with LEGO models.  

At each table are two students hunching over the robots, which they have spent the past 3 months perfecting.  Their fingers are poised to activate their robot on the announcer’s cue.  After a lively team introduction, the announcer declares “THREE, TWO, ONE, GO!!!”  Fingers press buttons, motors whirl, wheels spin, and off go the robots running around frantically solving challenges as fast as possible.  This is the accumulation of months of R&D, engineering, programming, trouble shooting, and practicing.  One robot cherry picks a green bottle while leaving orange ones undisturbed.  Another completes a patchwork quilt by sliding a square onto its correct mark.  Yet another knocks over little LEGO pins using a miniature bowling ball…. I am honored to be watching the future’s young scientists and engineers.  This is the West Michigan FIRST LEGO League Regional Tournament. 

48 teams composed of 3-10 students have come to show off their engineering and programming skills to judges, peers, and family.  Little do they know now, that the skills they have learned could land them a job in software engineering or mechanical design in the near future.  “The Sharks”, the home-schooled team I have mentored over the past few months, have prepared their robot to complete 9 out of 15 missions, which is quite an impressive number.  Teams have a stab at completing as many missions as possible during a 2 1/2 minute match, and to get even half of the missions accomplished invokes whooping and hollering from everyone watching. However, the points on the table only make up a quarter of the overall score.  There are three other judging criteria the teams must also complete.

There are also classrooms where interviewing is taking place.  Three categories of judging evaluate each team.  In the Technical judging room, teams are enthusiastically explaining the design process of their robot to a panel of judges who look over the team’s programs, building techniques, and strategies for completing the mission challenges.  Students demo their robots, answer questions, and illustrate problems they ran into during the development. 

In another room students are given a teamwork challenge to complete together.  The goal for this tournament was to build a gingerbread house out of the materials provided.  Seems simple right? Try having 20 hands working on a paper plate sized house simultaneously and see how simple it is.  The team must work together to solve the challenge, while exhibiting the FIRST LEGO League Core Values.  Surprisingly, the judges don’t care what the finished product looks like.  All they are observing is how well the students work together, include one another, and implement one another’s ideas into one cohesive solution. After the teamwork challenge is complete, the judges ask questions regarding their teamwork throughout their season.  What kind of problems did they face that they had to work together to solve?  How will teamwork help them in the future?

Finally, the least known aspect about FIRST LEGO League, and yet the most important, is the research project judging.  Along with the robot, there is a yearly real world theme that teams are given to research.  The goal is to find a problem within the subject, create a new innovative solution to the problem, and present it in a creative 5 minute presentation.  Teams present their research in a variety of different ways.  Presentations vary from infomercials promoting their solution, to plays acting out their problem, to songs explaining all that the team has learned. After their presentation, teams are asked about the feasibility of their solution, what experts in the field they talked to, and where they got their research from. (Read my previous post if you would like to know more about the research project for this years “Senior Solutions” challenge) 

All four of these events are run throughout the course of the day, with teams consistently running here and there going to their next interview or robot match.  But all of the hectic commotion is more than worth it.  Teams make new friends, learn new things, and have an opportunity to show off everything they worked on.  Oh, and did I mention trophies?  Yes.  Lots and lots of trophies, and the chance to advance to the state level competition!  At the end of the day there are over 20 trophies up for grabs, not including the 13 state qualifier trophies.  These awards range from Most Innovative Robot Design, to Most Creative Presentation, to the Rising Star Award – recognizing a rookie team that did an exceptional job for its first year.  

 

The closing ceremonies are always the funniest part of the tournament, with loud speakers blasting songs such as the Macarena, the Chicken Dance, and the Cha-Cha Slide.  Kids dance all over the place, form conga lines, and have a flat out good time.  After getting all the sillies out of the kids, the tournament director takes the microphone and begins awarding trophies.  When the team name is called, everyone cheers and the team stampedes down the bleachers to claim their reward. 

 

For “The Sharks”, the team I mentor, this closing ceremony was nerve wrecking!  They watched the trophies slowly disappear, as teams around them claimed the programming award, innovative solution award, and other such top honors.  Once all the standard awards were given out, the state qualifiers were announced.  Moving up the list, The Sharks grew more and more nervous. The tournament director holds up the giant first place trophy for all to see, announcing “And the first place grand champion, and final state qualifier goes to…” He then runs straight toward my team yelling at the top of his lungs, “THE SHARKS!!!!”.  We celebrated that night with some well deserved ice cream!  (No, the robot was not allowed to have any.)

The Sharks did an incredible job earning the champions award at the regional tournament. However, they still have a lot of work to do before the state competition on Saturday, December 8th.  Stay tuned to find out the results, and learn more about the team’s research project!

 

read more

If you have an all singing, all dancing app, with amazing features, does it really matter what it looks like?

By Heather Laine & Steve Thomas

I think I should open this article with two statements: 1) I’m not a graphic designer and 2) interface design isn’t just about eye candy.

I’ve seen some beautiful looking apps that after 5 minutes of test driving have forced me to abandon them.  An app that for example led me neatly into the help screen and then provided no means at all to exit it, short of closing the app, springs to mind.  Or an app that greeted me with a loud, prolonged horn blast which refused to stop – that got quit within minutes and never re-opened.

I’ve used some very ugly looking apps very efficiently for years.  The important thing was that they did what they were intended for, without any unnecessary fluff.  The buttons may have been left in their default state, but as we weren’t trying to sell the app, it really didn’t matter.  That said, I currently work with a rather beautifully skinned and designed internal CMS.  Do I work better because the buttons I’m clicking are turquoise and pulse prettily?  Possibly.

Form should follow function.  If your app exists to perform a task, then every part of the interface should facilitate that task, rather than wandering off into side alleys and distractions.  If your app is a game, the graphics should not only be professional looking and attractive, they should convey the atmosphere of your game to the user.  Is it a horror and suspense type game?  Fluffy kittens and roses will be inappropriate (in most situations at any rate).  Is it a utility, to assist with a business process?  It should be professional looking and sleek, without unnecessary window dressing.

Navigation is vital.  Are the buttons where the user expects them?  Do they look like their function?  If they are not actually labeled, it’s even more important that they conform to user expectations of what certain types of button should do.  If I used a button that looks like this:

 

and linked it to the zoom function in my app… people might become confused.  This type of icon has become firmly associated with RSS feeds, so even though I could imagine it representing something getting bigger, it would not be a good idea to use it in this way.

I asked our resident graphic designer, Steve Thomas, for some tips I could share with you.  He came up with some top tips to bear in mind when designing your mobile app, and this beautiful screenshot of an app to consider.

Tips on good UI Design from the Master

Don’t reinvent the wheel
When considering the layout of your UI, take a look at how other Apps work and try and use a layout that people will be familiar with.

We often take if for granted that App users learn from their experience and are familiar with how how Apps behave.  So take advantage of that familiarity and use it within your App.

Everything in the right place
Make sure your buttons are clearly labeled and that they behave as they should.  So in our example, we have back button in the top left corner, action button in the top right (this can also be a menu or home button) with navigation along the bottom.

Warning: Add an action item within the navigation and the App may not behave as the user would expect it to behave.  So make sure your navigation items and action items are clearly separated.

Hit and Active states
We have used on (or active) states within the navigation so the user knows where they are within the App at all times.  You can also add ‘hit’ states where the button highlights on order to enhance the user experience and further engage the user.

Button sizes
When designing the buttons for your mobile App, remember that a finger is a lot less precise compared to a mouse cursor or stylus.  So make your buttons large enough so the user has control, but not so large that they dominate the screen.

All useful considerations, thank you Steve.

If you are making an application that needs to work across several different platforms and devices, e.g. on Mac and Windows desktop, as well as on iOS and Android phones, you have some very particular challenges.  

Firstly, there is the size and shape issue – an Android phone can be tiny, a Mac desktop can be huge.  Designing something that will work in both places means either some serious scaling up and down, or completely separate sets of interface elements.  You might want to look at a lesson on our website that discusses different ways of approaching this issue.

But it’s not just about size.  A Windows user expects buttons and menus to look different from those on a Mac, and be in different places.  Android and iOS devices have a distinctly different look and feel.  You have two choices here.  You can either re-skin your app to conform to the user interface expectations on each platform, or you can choose to ignore the conventions and create a “universal” interface for your app, that will function everywhere and be distinctively different.  The latter option is dangerous – if you’re going to do this, you had better be a really excellent designer – but it can be done successfully, if you are really sure its the best route for your particular app.

What do you think?  Do you have an app you are proud of?  Something distinctly different to share?  What are your top design tips?  We’d love to hear from you, do enter a comment below!

read more