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

by Monte Goulding 

Monte Goulding lives on a small farm in Tasmania, Australia where he built a straw bale house. When not working at M E R Goulding – Software development he enjoys spending time with the family, pretending to be a farmer, mountain bike riding, diving for and eating abalone.

_____________________________________________________________________________________________

Developing third-party extensions for a developer tool is a challenging business to run.  The market is an unknown size and only a small percentage are involved in mailing lists and user groups so it’s very difficult to make people aware of what you provide.

However, I’ve long believed that a proliferation of third party extensions can make a platform like LiveCode shine.  It can also be very fulfilling because you are creating tools used by people in a community you are involved in.  Your code is used in a wide array of apps all over the world and it’s really great when you find out what someone has achieved with it.

The flip side of that is developers rightly expect responsive support and well maintained extensions.  It’s difficult to strike the right balance between sharing with your community and the business aspects of doing so and I know of many great potential extensions that aren’t shared as a result.  

The business model for mergExt has evolved over the past year in an effort to find the right balance.  Product development is usually 50-70% funded by the community that need an external or feature developed so they can implement their app.  The rest of the funding (including for support and long term maintenance) comes from product sales. The whole concept is to create a win-win-win situation for the community and platform, the client that needs the feature implemented and my business.

Other times product development happens because I identify a great feature that I think users will love and I get a strong urge to spend a rainy weekend implementing it and sharing it with my fellow LiveCoders.

With roughly a billion users worldwide Facebook has become one of the most important marketing tools ever.  When iOS 6 by Apple was announced, I asked the community which features they would most like to see developed into an external.  Facebook lead the poll by a long way.  When I got my hands on a beta version I could see why.  Both the Social framework and the UIActivityViewController made sharing content on social networks a breeze.  

The next rainy weekend I targeted the UIActivityViewController which has great bang for buck in terms of what you get for the amount of code you need to write.  As with everything else in LiveCode it had to be done in a way that made it super easy to use.  I added it to my mergPop external with the mergPopActivity command.  With a single command LiveCode iOS apps could now share data to Facebook, Twitter, Messages, Mail and more. A simple script like this:

on touchEnd
mergPopActivity “This is the best app ever”,,appStoreURL
end touchEnd

Presents this to the user:

From there the user can choose whichever service they want to use to share your message. The addition to mergPop (one of my most popular releases) was very well received, however, it wasn’t long before Jaime Stuart from EuroTalk asked to be able to post to Facebook without going via mergPopActivity. He wanted to have a facebook button rather than a share button.  I had already looked at the Social framework but at the time I was in the midst of resolving some lingering issues resulting from the changes to iOS externals required by LiveCode 5.5.2.  

Once resolved I set to work implementing mergSocial as a natural successor to the existing mergTweet external that was based on the iOS 5 Twitter framework.  Once again it had to be super easy to use so even someone using LiveCode for the first time could see it’s easy to share on social networks. I ended up implementing one function to check if a service is available and another to present the dialog for the user to send a post.  It’s so simple to post to Facebook Objective-C coders will get jealous:

on touchEnd
mergSocial “facebook”,“Hello mergExt!”,picOfMyLittleGirl,”http://mergext.com”
end touchEnd

Presents this to the user:

 

From there the user can cancel, edit the message and post.  

For more information, visit http://goulding.ws/ or http://www.facebook.com/mergoulding

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.

—————-

I’m standing by a 4×8 foot table made of 2x4s and plywood.  On the table is a colorful mat with lines, patterns, and a home base.  Strewn about the mat is a wide variety of LEGO models.  Bowling pins are set up in one corner, stair steps leading up to a rocking platform sits in the middle.  A LEGO stove sits to one side, burners showing on. 

These models, along with ten others, are being scrutinized and discussed by 8 middle school students.  “Well, we could put the blue quilts out on their mark first, then complete similarity, then send the dog back to base.”  Says one team member.  “Yea!  Then we could grab the broken chair on the way back!”  Says another.  What are these kids discussing, and why am I watching?  They are The Sharks, a homeschooled FIRST LEGO League Team from Michigan,and I am their mentor.

Front to back, left to right: Trey, Cole, Brennan, Jamin, Abby, Ryan, Ashly, Alex

FIRST stands for “For Inspiration and Recognition of Science and Technology” and was founded by Segway inventor Dean Kamen.  FIRST LEGO League (aka FLL) is a science and technology competition for elementary and middle school students ranging from 9-14 years old.  Last year alone there were over 18,000 teams from all over the world.  During that year, The Sharks were honored to win the Michigan state competition, and asked to represent Michigan at the world championship in St. Louis, MO.  Only 80 teams out of that 18,000 were invited.

FLL is comprised of 3 sections, the Robot Game, the Research Project, and Core Values, also known as teamwork.  Each year there is a theme that encompasses the research project and robot game.  Themes have ranged from how to conserve energy, to making transportation safer and easier, to keeping food safe from contamination.  This year’s theme is all about making the lives of seniors better.  Teams are challenged to build and program a robot out of LEGO to complete challenges on a table to earn points.  Each challenge relates to senior living/challenges, such as physical therapy, or needing the use of a service dog.  Teams have from the beginning of September, to the middle of November to build and program their robot to complete as many missions as possible. 

So far, The Sharks have achieved 235 of a possible 723.  This year The Sharks have also implemented LiveCode.  We have created a scoring app which allows teams to quickly time, score, save, and share their robot score!  Due to the speedy nature of LiveCode, we were able to get the app up and running within 3 days of the challenge announcement.  We are using this as a fundraiser to pay for tournament fees and the like.

However, the robot game is only a third of challenge.  Another part of the challenge involves a research project.  The goal for this year is to find a problem seniors face today, and come up with an innovative solution.  Each team must find a “senior partner” who will help them learn more about senior life, and problems they have.  Once they narrow their problem down, teams must find an expert in the field who is currently working on the problem.  The teams will then take this information, formulate their own innovative solution, and present it to those who it would benefit. Currently The Sharks have found that falling is a big problem, and are going to research preventative solutions.

The last third of the challenge is Core Values.  On the FLL website, The FLL Core Values are described as “The cornerstones of the FLL program.  They are among the fundamental elements that distinguish FLL from other programs of its kind.  By embracing the Core Values, participants learn that friendly competition and mutual gain are not separate goals, and that helping one another is the foundation of teamwork.”  The teams learn that teamwork is what holds the other two parts of the challenge together.

The Sharks and Jarren in the black “innovate, don’t imitated” shirt.

FIRST LEGO League is a big commitment, but has huge rewards.  Students will gain knowledge and experience in science, technology, communications, research, and presentation.  FLL not only gets kids excited about science and technology, but provides the life skills essential for making the world a better place.

If you would like to learn more about The Sharks, or FIRST in general, visit www.paradiseteams.org, or www.firstlegoleague.org.  To check out our app, go to http://itunes.com/apps/fllseniorsolutionsscorekeeper.

 

 

read more