Many problems on viewer 3

For all the loyal customers, this is to address the issue from the inventory problems. Viewer 3 with the far latest version does not fetch inventory from the server even though there is free from cache and all the previous preload items. This is strong recommend residents to use firestorm to get a better, stabler working environment. We are once again apologize for the inconvenience. 

HKM Server is now added with new feature

Coming in the new year, we are now introducing “Assignment”. Account owners can now share the access with the account manager. Since the owner of the account may not want to share the same password with the account manager and they may often want to outsource the job for the account manager to handle. This is why the new feature comes in handy for solving the issue. Just login the account with the owner password and go to >extra > adminstration. There you will see the Management feature on the bottom and you can share the special code generated for the new account manager by turning it on.

Write me a line for any query regarding.

HKM Server is now fixed up!

With serving tens and thousands of customers in world for auto releases and updates of the new products periodically, we have developed a better inventory system where you can have control on your smart phones. Come check it out now with your IPHONE5, IPHONE4, IPONHE4S, IPHONE 3, IPODTOUCH, Android Galaxy S2, ANDROID LG, PALM.

LOGIN HERE

New added features:

  • Product UUID to be viewed by the public.
  • Revamped in the deploy-release function.

Recruiting new shape for the tops producers!

Previously we have designed SKIN BRA PRODUCERS and TOPS PRODUCERS series for making tens and thousands of implant clothing in world. Thanks for the contributions from all the supporters and implant fans, we have worked the best to bring all the easy and secured tool sets to the designers. Due to stipulations from the brand designers, there were few suggestions from the appearance of the tools. We are now undergoing brand new revampment of these tools to bringing brand new looks and feels to SL designers. Got ideas? we will love take into considerations from your suggestions. Please submit your queries by replying this post thank you!

Redeliver system

This is all new web interface for our customers. All customers need to come visit the main store from this URL.

http://maps.secondlife.com/secondlife/Ferox/184/74/22

There is delivery board you just need to click on the board and a secret url will be sent to your chat screen. Click on the URL given from the system and you will be able browse all your previous products from HKM. If you see one your products have the newer version and you don’t then you can click on “update” button and it will deliver to you right away! Come try it now.

Basic Scripting & Mathematic Principles.

Welcome to Scripting 1 – Basic Scripting & Mathematic Principles.

Have you ever wanted to learn scripting in Second Life, but didn’t know where to begin? This course is for you!

During this first introductory class we will make a box talk, make a simple calculator, and have a brief look at physics in Second Life.

NOTE: This class is NOT for advanced users!

PREREQUISTE: Basic knowlege of building. ( Must be able to create a box prim and navigate the edit window ).

We will start discuss the basics of scripting, starting from the very beginning.

Directions: Class is held in the Construction Zone of cloud city campus. (use the elevator)

Examples:

  1. Basic Scripting
  2. 2+2
  3. Recuring Addition
  4. Physics Demonstration
  5. Sensor Loop
  6. Following Box

Tutorial LSL 103 Class Note

Basic Scripting 103 (Beginners with no programming experience)
Welcome to my basic scripting class.
~============== Introduction ======================
This class is for beginners who don’t have any experience at all in programming.
If you already have scripting experience in any other language, please consider to take one of the intermediate classes instead. You are welcome to stay but it may be boring 😉
We’re hiring teachers here at the Academy of Second Learning, so if you’d like to help us bring great classes to Second Life, please pick up an application from the blue square sign outside.
Today I will tell you what a script is and how you can create and change it.
This will be very basic and I try to explain anything that is important to start your first script.
Anyway, you may find some stuff confusing if you hear it the first time, and you don’t need to understand all the technical details to create your first script.
So please bear with me, if some of it sounds Chinese to you. You will understand it later. If you have questions, please wait until I did all the explanations.
I will stop from time to time and give you a chance to ask questions.
~========= Chat Issues =============
Make sure to open your chat history (you can use CTRL-H to do this). You can catch up with chat lines that you may have missed.
Later on, after the class, you will be able to select all the chat lines with your mouse, or just click into it and press CTRL-A to select all.
You can then copy the chat history into the clipboard by pressing CTRL-C and pasting it later in any text editor of your choice or in a new note card by pressing CTRL-V.
~================ Presenter issues ==============
I hope you can see the presenter screen with the screenshots. If it is blurry, please wait a while until the images are loaded. It should become clear after a minute.
You can speed it up if you zoom in your camera to make it full screen. You can also right-click on it and choose “Edit”.
Even if you are not allowed to edit the object, it will put the image first into the loading-queue, which means, the presenter image will load next on your computer.
~=============================================
We will create our own script today from scratch. Anyway you will get class notes after class to review all the details.
For now it’s important that you just get a hands-on experience with your first script.
If you have to choose between understanding and a working script, choose the working script and re-read the class notes later, that’s much more fun 😉
Anyway feel free to stop me if I’m going too fast for you to read all the stuff 😉
~===================== Default Script basics =========================
We have learned in “basic scripting 102” how to create a default script.
To do that, please REZ a PRIM (any prim will do), I will do a BOX here.
It’s always a good idea to rename everything after creation.
So go to the GENERAL tab and name your object “My scripted Object”
Now, change to the CONTENT tab and click on NEW SCRIPT
There will be now a new script named NEW SCRIPT
You can rename it to a more meaningful name.
RIGHT-CLICK on the name and choose RENAME
Name it now “My first Script”
Now open the script by DOUBLE-CLICKing it
You can also RIGHT-CLICK and choose OPEN
You now see the default script with the default state and the events state_entry and touch_start.
Now prevent the spam from the script by adding the characters // at the beginning of the line:
// llSay(0, “Hello, Avatar!”);
The // will tell the script to ignore the whole line, you know that from the 102 class already.
When you have disabled the llSay-Line, and you save your script now (just click on the save button), we should no longer have these “Hello, Avatar” in the chat.
Anybody could manage that?
~=============== Functions ================
Now, let’s go on to change the Function call in touch_start:
To avoid text spam from the object here in class, change the line with llSay to another function. The new Function is llOwnerSay and you have to change the line like this:
llOwnerSay(“Touched”);
Make sure you delete the first parameter (the number 0 and the comma) from the parameter list.
Then hit “save” and wait a moment. Saving the script may need a few seconds. It will say “Save complete” if there was no error in the script.
All okay so far?
llOwnerSay has the same effect as llSay, but the text will only show up in the chat window of the object’s owner.
So everybody can only hear their own object.
You can do other fancy things in the touch_start event. We will come back to that later.
~======================== add line llText to event_start =======
Now add the following line in the state_entry section. Just make sure you put the line between the curly brackets { and }
llSetText(“I am a scripted object”, <1, 1, 1>, 1);
If you click on save, and you don’t see an error message, there should be a text message hovering over your object.
Does it work for everybody?
Now let me explain what you just have done 😉
llSetText is a Function that needs three parameters.
The first is a string with the text that shall show over the object.
The second is a special thing with three numbers. This “thing” is included in < and > and it is called a VECTOR.
A vector is just a set of three numbers, normally used for position coordinates, but in this case it is used for a color.
The numbers are the intensity for the colors RED, GREEN and BLUE, where 1 means “full intensity” and 0 means “no intensity”
So <1, 1, 1> is WHITE, while <0, 0, 0> is BLACK
Other colors can be <1, 0, 0> for RED, or <0.5, 0.5, 0.5> for GREY.
Just try out several numbers. Just make sure the number needs a point as decimal point, and each number is separated by a comma.
The third parameter for llSetText is ALPHA which means the transparency of the text.
In this case, 1 means it has no transparency, 0 means it is transparent (invisible), and you can use any number between like 0.3 or 0.8 for example.
There is something special: If you remove the llSetText() in your script, the text will NOT go away 😉
This is because the text is an attribute of the object. If it is set, it will stick until you change it.
The only way to remove a hover text is to apply a blank text to the object.
To do this, change your line to:
llSetText(“”, <1, 1, 1>, 1);
Make sure you use the quotation mark ” twice to indicate an empty text.
If you now save the script, the text will disappear.
Does it work?
~========== Conclusion ==============
This concludes this class.
Now you will be able to create your own simple script.
You are able to use llSetText to add a hovering Text to your object and remove it later.
You are able to use llSay and llOwnerSay to let your Object speak with everybody or just with you.
Thanks for your time 😉

Tutorial LSL 102 Class Note

Basic Scripting 102 (Beginners with no programming experience)

Welcome again to my basic scripting class.

~============== Introduction ======================

This class is for beginners who don’t have any experience at all in programming.

If you already have scripting experience in any other language, please consider to take one of the intermediate classes instead. You are welcome to stay but it may be boring 😉

We’re hiring teachers here at the Academy of Second Learning, so if you’d like to help us bring great classes to Second Life, please pick up an application from the blue square sign outside.

Today I will tell you what a script is and how you can create and change it.

This will be very basic and I try to explain anything that is important to start your first script.

Anyway, you may find some stuff confusing if you hear it the first time, and you don’t need to understand all the technical details to create your first script.

So please bear with me, if some of it sounds Chinese to you. You will understand it later. If you have questions, please wait until I did all the explanations.

I will stop from time to time and give you a chance to ask questions.

~========= Chat Issues =============

Make sure to open your chat history (you can use CTRL-H to do this). You can catch up with chat lines that you may have missed.

Later on, after the class, you will be able to select all the chat lines with your mouse, or just click into it and press CTRL-A to select all.

You can then copy the chat history into the clipboard by pressing CTRL-C and pasting it later in any text editor of your choice or in a new note card by pressing CTRL-V.

~================ Presenter issues ==============

I hope you can see the presenter screen with the screenshots. If it is blurry, please wait a while until the images are loaded. It should become clear after a minute.

You can speed it up if you zoom in your camera to make it full screen. You can also right-click on it and choose “Edit”.

Even if you are not allowed to edit the object, it will put the image first into the loading-queue, which means, the presenter image will load next on your computer.

~=============================================

We will create our own script today from scratch. Anyway you will get class notes after class to review all the details.

For now it’s important that you just get a hands-on experience with your first script.

If you have to choose between understanding and a working script, choose the working script and re-read the class notes later, that’s much more fun 😉

Anyway feel free to stop me if I’m going too fast for you to read all the stuff 😉

~===================== Default Script basics =========================

So let’s look how we can create a script.

To do that, please REZ a PRIM (any prim will do), I will do a BOX here.

It’s always a good idea to rename everything after creation.

So go to the GENERAL tab and name your object “My scripted Object”

Now, change to the CONTENT tab and click on NEW SCRIPT

There will be now a new script named NEW SCRIPT

You can rename it to a more meaningful name.

RIGHT-CLICK on the name and choose RENAME

Name it now “My first Script”

Now open the script by DOUBLE-CLICKing it

You can also RIGHT-CLICK and choose OPEN

What do you see?

It is an editor window, quite similar to the editor where you write note cards.

The differences are:

1. There is a special Menu available

2. There is some kind of status information at the bottom of the window

3. You will see the text in different colors.

I will tell you more about the editor in the next class, when we start to make changes in the script ourselves.

For now, I will just discuss the structure of the script as you see it here.

The very important part for Beginners:

Don’t be scared by the structure that you see in this script. It’s called the “Default Script” that will be created every time when you create a new script.

You can see it like a skeleton. There is no need to change that skeleton or add anything to it. We will just add some meat to it now.

You will be able to understand the general structure later, for now we will just change the lines that we have already in the default script.

Anyway, I will explain what you see here, to make it easier to understand later, if you continue your scripting experience.

First, there is the word “default”

That means, it’s the start of the DEFAULT state for this script or object that is attached to the script

Every script has a DEFAULT STATE.

You will recognize that some lines are surrounded by curly brackets. These curly brackets build a CODE BLOCK.

That means all lines between a { and } belong together. You can imagine it as a paragraph in a book.

Code blocks are useful if you want to group more than one line of code (you may also say: more than one sentence in one paragraph).

There are some exceptions where you don’t need these code blocks, but it won’t hurt to use them anyway. So for beginners, it’s always a good idea to use them as shown in the default script.

For each opening curly brace { there must be a closing one.

To make it much more complicated, these Block can be NESTED, that means you can have such a CODE BLOCK inside another CODE BLOCK.

To make it more readable, these blocks are indented to show what belongs together.

So for Beginners: Just don’t touch the curly brackets unless you really know what you are doing 😉

All the lines that are between the first { and the last } will belong to the DEFAULT STATE that we are going to ignore for this class 😉

~===================== The Event ======================

The first line inside this default state reads:

state_entry()

This is an EVENT.

Not to confuse with a party or education event in SL 😉

The EVENT concept maybe hard to understand for somebody who has not programmed before, so let’s try to say it in simple words:

Just Imagine it’s something that just HAPPENS without the need to TELL the Object to do anything specific.

For example: state_entry will happen every time when the script is started or if you change and save your script for that object. You can’t stop it, and you can’t repeat it at your will.

It just happens, like your object has a life of its own.

And what happens, when you create your script? It tells you “Hello, Avatar” in the Main Chat. That’s a nasty thing in classes, because it will spam all over the chat with these “Hello, Avatar” lines 😉

To prevent all this spam, add the characters // at the beginning of the line:

for Example: // llSay(0, “Hello, Avatar!”);

The // will tell the script to ignore the rest of the line.

This is useful if you want to disable a line in a script, but you don’t want to delete it entirely.

It will also be used for comments in a script. For example it you want to document what you are doing in the script.

Theses comments are useful for you, if you want to review and change your own scripts later, or for other people who want to use or change your script.

You often find such comments

like: // enter your e-mail address in the next line

Or: // Copyright by Jim Gustafson

or: // this is a simple vendor script, contact Jim Gustafson if you need help

When you have disabled the llSay-Line, and you save your script now (just click on the save button), we should no longer have these “Hello, Avatar” in the chat.

Everybody could manage that?

~=============== Functions ================

Now, let’s go on with the default script

We will find another event in the script: touch_start

This event happens every time, when the object is touched. You will find this line in the code block for touch_start:

llSay(0, “Touched”);

llSay() is a FUNCTION in LSL

BTW: LSL is short for Linden Scripting Language 😉

A function is something that you can CALL in LSL

It’s like Ali Baba calling “Open Sesame” to open the door 😉

It is like giving your Object a command like in your life if you say “come here!” or “go away!”, or “buy me a drink!”;

Sometimes, you have to PASS one or more PARAMETER to this FUNCTION

They are in the round brackets and will be separated by commas

Parameters are like detailed instructions for a function. In real life you would say “Buy me a drink! I like a red wine”.

If you would say it like a computer you would say:

buy_me_drink(“wine”, “red”);

buy_me_drink is the FUNCTION here,

“wine” and “red” are two PARAMETERS for this function.

You may have noticed, that every function call is ended by a semicolon ;

That’s not part of a smiley – it is part of the SYNTAX

SYNTAX is the GRAMMAR of your script. If you do it wrong, your object won’t understand you 😉

In English, if you use wrong grammar, the other person may understand you anyway.

But in Computer-Language, the computer has no mercy.

If the SYNTAX is wrong, the computer WON’T WORK.

But no panic!

The computer will tell you, if something goes wrong.

Just try it out.

Remove the semicolon at the end of the line that says llSay(0, “Touched”), then click SAVE.

You will get a message in the editor:

(10, 4) : ERROR : Syntax error

That means:

In line 10 column 4 there is a problem.

Anybody have the same or a similar result?

~================ explain error messages ================

The computer tries to read ahead, because it expects a semicolon at the end of the command line.

If it is not found in line 9, it will commence to line 10

And there, it will find the closing curly brace } that indicates the END OF the CODE BLOCK

So, sometimes, error messages will not exactly point you to the faulty line …

… but maybe to the next line in the script.

If you add the semicolon again …

… you can save the script without error.

Succeeded everybody?

~==================== explain llSay =====================

As we have seen, the function llSay() is used to print a text in the main chat.

The first parameter is the number 0

That means the output goes to channel 0 which is the main chat window.

The second parameter is a string.

That is the text that is printed into the chat.

In a script you can have different types of data that can be passed as function parameters.

For example 0 is an integer; integer is just another name for a number

A string is a sequence of letters that can be displayed in a chat for example

You can look it up in the Wiki:

http://rpgstats.com/wiki/index.php?title=LlSay

A Wiki is a special Website, where knowledgeable people can build some kind of documentation that can be changed easily.

If you have a chance to open the URL in a browser, you can do this now. If not, you can explore the LSL-Wiki later.

The LSL-Wiki is the best reference for scripting at the moment.

It’s not complete, that means some explanations are still missing. But it will be completed over time.

You may also notice, that every Function starts with ll which is short for Linden-Language and must be two lower case letter L

For llSay you will find a so called “PROTOTYPE” of the function in the Wiki:

llSay(integer channel, string text)

That means, llSay is called with two parameters (here named channel and text)

The first one must be an integer

The second one must be a string

If you read further in the Wiki, you will find:

“Says text on the specified chat channel. The range is a 20m radius sphere.”

This is the explanation of the function. The names of the prototype parameter are used here to explain the usage of the function.

The next line in the wiki is a note:

“Note: A long string for text will be truncated to 255 bytes.”

For other functions you may see a lot more explanation and more notes, but llSay is a very easy and basic function.

Any questions so far?

~================== changing llSay to llOwnerSay in touch_start ========

To avoid text spam from the object here in class, change the line with llSay to another function. The new Function is llOwnerSay and you have to change the line like this:

llOwnerSay(“Touched”);

Make sure you delete the first parameter (the number 0 and the comma) from the parameter list.

Then hit “save” and wait a moment. Saving the script may need a few seconds. It will say “Save complete” if there was no error in the script.

All okay so far?

llOwnerSay has the same effect as llSay, but the text will only show up in the chat window of the object’s owner.

So everybody can only hear their own object.

You can do other fancy things in the touch_start event. We will come back to that later in the next class “basic scripting 103”.

~========== The editor ==============

For now, we will just explore the script editor.

You see the different colors. Events and Functions do have their own colors.

This helps to avoid typos. If you write something wrong, it will not have the correct color.

For example: States and functions are red.

Events are blue

Comments (beginning with //) are orange

So you can easily see that something is wrong.

The editor will also help you with code blocks.

Delete the whole code block in state_entry, just select all lines from the opening curly bracket { after state_entry until the closing brackets } and hit delete.

Now enter a new opening curly bracket after state_entry()

To do that, place your cursor directly after state_entry() and press the RETURN key

The editor will INDENT your cursor automatically under state_entry()

Now type the curly brace { and hit RETURN again

You will see, the cursor is INDENTED again. There you will be able to write all your commands that belong to this code block. In this case type:

llOwnerSay(“Hello”);

(don’t forget to end the line with a semicolon 😉

Press RETURN again. The cursor will be placed indented directly under your line.

Now enter the closing curly brace }

You see, that the cursor will change the indentation and jump back to the left.

This method does not always work properly. For example if you indent your line manually by pressing the TAB-Key (Tabulator key), it can be messed up.

For that reason, it’s always a good idea to count your opening and closing brackets afterwards 😉

What I do usually: I close every bracket immediately and then fill in a new line between them. Let’s try that:

Delete the code block again.

Place the cursor after state_enty() and press RETURN

The cursor is now indented under state_entry, now type the opening brace { and press RETURN

Now type the closing brace }

Your code block is now lined up correctly but you don’t have anything between the brackets.

Now GO UP one line, place the cursor past the opening brace {

… and press RETURN.

Now you can enter your line:

llOwnerSay(“Hello”);

This seems to be more complicated, but will prevent that you forget to close brackets.

~========== Conclusion ==============

This concludes this class.

Please take the class notes from the big box.

Now you will be able to create your own simple script.

You are able to use the script editor

You are able find simple syntax errors in the script and fix them.

At last, maybe you can do me a favor:

These classes are free of charge, because ASL has sponsors.

These sponsors would like to know how the classes are accepted by the students.

So please fill out the feedback form that I gave you with the class notes and drop it back in the ASL Survey Box (the blue scroll near the landing point)

Thanks for your time 😉

LSL Tutorial Class Note 101

Basic Scripting 101 (Beginners with no programming experience)

Welcome to my basic scripting class.
~============== Introduction ======================
This class is for beginners who don’t have any experience at all in programming.

If you already have scripting experience in any other language, please consider to take one of the intermediate classes instead. You are welcome to stay but it may be boring 😉

We’re hiring teachers here at the Academy of Second Learning, so if you’d like to help us bring great classes to Second Life, please pick up an application from the blue square sign outside.

Today I will tell you why we need scripts and where you will find more information about scripting,

This will be very basic and I will explain you some theory about scripting and show you some examples.

I will stop from time to time and give you a chance to ask questions.

~========= Chat Issues =============

Make sure to open your chat history (you can use CTRL-H to do this). You can catch up with chat lines that you may have missed.

Later on, after the class, you will be able to select all the chat lines with your mouse, or just click into it and press CTRL-A to select all.

You can then copy the chat history into the clipboard by pressing CTRL-C and pasting it later in any text editor of your choice or in a new note card by pressing CTRL-V.

~================ Presenter issues ==============

I hope you can see the presenter screen with the screenshots. If it is blurry, please wait a while until the images are loaded. It should become clear after a minute.

You can speed it up if you zoom in your camera to make it full screen. You can also right-click on it and choose “Edit”.

Even if you are not allowed to edit the object, it will put the image first into the loading-queue, which means, the presenter image will load next on your computer.

~===================== Default Script ========================

Why do we use Scripting in SL?

It’s because our objects should do things that a normal chair or table would not do.

Imagine these things in Real Life. You would not expect a chair or a table to interact with you or with the environment.

On the other hand, look at your TV, your radio, your toaster. You expect them to “do” something for you.

For example showing your favorite TV-show, or heating up your toast.

It’s the same in SL. If you see a radio somewhere, it just could be a “dead” item that just looks nice.

But if it contains a script, it would be able to play music for example.

To do this, the object need to “know” when it should start playing the music, and maybe it should be able to play different music of your choice.

That’s why we need scripts in objects.

For example, an object can give you things when you touch it. Or you can open a door when you touch it. Or the object sells you something if you pay it.

All the games in the casinos are heavily scripted objects. But also some of your jewelry may contain a script.

For example a bling script to produce these glitter effects for shiny shoes or earrings.

Let’s have some examples:

Click on this box, it contains the class notes for this class and some sample scripts that we need for an exercise that we will do later.

~============== Show a notecard giver ================

This is a simple notecard giver. You can touch it and it will give you a notecard.

~============= Show diamond ring =============

This is a simple diamond ring that I build in class. It contains a script that produces something that is called “particles”.

The particles look like bright sparks that come out of the object. This is called “bling”.

Bling looks very nice but sim owners don’t like it very much, because it will add some lag to the sim.

So if you are asked to turn it off, be kind and detach the object if possible. If you don’t want to detach it, make sure you can turn the bling off. Most scripts have a special command to do that.

Anyway, it is always better to detach a scripted object than to just turn off the script. Even a script that is turned off can cause lag. So make sure you dress up only with non-scripted objects if you plan to attend a meeting where you expect many people.

~~~~~~~~~~~~~~ Show teleporter ~~~~~~~~~~~~~~~~~~~

This is a simple telporter. It just contains a simple sit and unsit script that will place me about 3 meters above the prim when I am sitting on it.

After that, it will unseat me and I can walk around again.

~============ apply a script to an object ===========

Our first exercise will be, to apply a script to an object.

Rez a prim, a normal box will do fine. You can change color and texture to what you like just to make it easier to find your own object later 😉

It’s always a good idea to rename everything after creation.

So go to the GENERAL tab and name your object “My scripted Object”

Now change to the content tab. Drag my script “example script” from your inventory to the content tab.

It will now appear in the content folder.

Now you can close the edit window for your object. That’s all you need to put a script into a simple object.

~============ Try out the example script ============

Now, try the example script.

If you touch the box, it will jump 1 meter high and stay there.

If you touch it again, it will go down again.

The Scripting is done in a special scripting language that’s called LSL.

LSL is short for Linden Scripting Language.

The LSL-Wiki is the best reference for scripting at the moment.

http://rpgstats.com/wiki/index.php

A Wiki is a special Website, where knowledgeable people can build some kind of documentation that can be changed easily.

If you have a chance to open the URL in a browser, you can do this now. If not, you can explore the LSL-Wiki later.

It’s not complete, that means some explanations are still missing. But it will be completed over time.

You may also notice, that every Function starts with ll which is short for Linden-Language and must be two lower case letter L

You will be able to create your own basic script in the next class “basic scripting 102” where we will create a default script and change a few lines in there.

Any questions so far, before I finish this class for today?

~========== Conclusion ==============

This concludes this class.

Now you now know why we use scripting in SL

You are able to apply a given script to any of your own objects. And you know that there exists a special website with more information about LSL

At last, maybe you can do me a favor:

These classes are free of charge, because ASL has sponsors.

These sponsors would like to know how the classes are accepted by the students.

So please fill out the feedback form that I gave you with the class notes and drop it back in the ASL Survey Box (the blue scroll near the landing point)

Thanks for your time 😉

Mobile Apps Are Intermittent-Use Apps

Jakob Nielsen‘s Alertbox, February 10, 2010:

iPhone Apps Need Low Starting Hurdles

Summary:
Most mobile applications are used only intermittently, so they must be especially easy during initial use. In particular, upfront registration shouldn’t be required before users experience an app’s benefits.

In preparation for our iPhone Apps Usability seminar, I’ve been sitting through numerous test sessions watching iPhone owners use hundreds of applications.

Based on these sessions, we’ve identified many specific usability guidelines that make it easier for people to use apps on the small touch screen. Clearly, current apps are far from user-experience nirvana.

In many ways, these test sessions reminded me of testing early Macintosh applications in 1986, when interaction designers hadn’t yet figured out how to use the mouse and a mid-sized GUI. Now they need to get better at supporting fingers and a tiny GUI. There are plenty of guidelines for the seminar — in fact, I’ve never failed to derive a rich day’s worth of material whenever we test a new generation of user interfaces. The “master guideline” remains the same as in 1986:don’t port a UI from an old interface paradigm to a new one. In the past, this meant not slapping a GUI on top of something that was inherently a clunky mainframe flow. Now, it means not adding touch-screen access to a desktop-oriented direct manipulation design — users can’t touch as precisely as they can click, so the number of manipulable graphical objects should be much smaller (so that each one can be much bigger).

Still, despite the weaknesses, my main conclusion from watching iPhone app users is that they suffered much less misery than users in our mobile website tests. In fact, testing people using iPhone apps produced happier outcomes than testing people attempting to use websites on the same phone.

On mobile devices, applications are easier to use than websites. (Given the current state of affairs; browser-based sites would be easier to use if designers started following more mobile usability guidelines.)

Why are apps better than sites for mobile? Because the more impoverished the device, the more the design must be optimized for the platform’s exact abilities, instead of bowing to a cross-platform common denominator.

Mobile Apps Are Intermittent-Use Apps

A very strong conclusion from our iPhone study is that people install many more apps than they actually use.

In the first part of each session, we asked users to walk us through their own iPhone apps. We frequently heard comments such as, “I downloaded this because [it sounded cool/a friend recommended it], but I haven’t had time to try it.” Users also often said something like, “I used this a few times right after I downloaded it, but I’m not using it anymore — I just haven’t gotten around to deleting it.”

The first conclusion from this finding is that pure download numbers are obviously irrelevant. To measure your app’s success, you must measure actual use. And, to assess whether you’re really meeting user needs, you must go even further and measure sustained use. If people use something a few times and then give up on it, you have a failed mobile design on your hands.

A few mobile apps do get frequent use, ranging from Facebook to the Weather Channel. But most businesses can’t realistically aspire to enter this category; mobile apps have different usability criteria than core desktop applications, as well as the mission-critical enterprise software that people use every day on the job.

Mobile mainly equals intermittent use. This does indicate a deeper level of user commitment than the ephemeral applications we often study on websites.

An example of a Web-based ephemeral app would be the customization and configurationutilities often found on car sites. For such apps, users have zero commitment and arrive at the first screen with no knowledge of the functionality beyond what they may have gleaned from passing through previous pages on that site. (And we all know how little users read during most website visits.)

Mobile apps score a little better than ephemeral website apps, because users actively decide to install them. This creates a minimum level of commitment to explore the app — though, as we found, this level is often very low indeed. Still, it’s higher than zero.

Second, the app icon is a continuous presence on the phone, which acts as a tiny voice gnawing at the user to try it out. Again, this isn’t a very strong force; humans are great at selective attention (as further discussed in our seminar on the human mind). Basically, people tune out anything they don’t really want to pay attention to, so users’ eyes pass by unused icons very quickly.

These are simply facts of the overall iPhone user experience: an app is easy to download from the App Store, and social pressure causes many “fun” apps to migrate quickly through large user pools. As a result, the “Springboard” (the app launching page) quickly becomes polluted with frivolous icons that people don’t really need and don’t use after leaving the bar or pub that evening.

If you’re designing a “serious” business app that you think offers real benefits to your customers, you might feel above the fray of rude-bodily-noise apps. But you’re not. Frequent readers of this column might recall Jakob’s Law of the Web User Experience: Users spend most of their time on other sites (than your site). Your website is part of the Web ecosystem, and your site’s usability is dictated by the overall Web user experience, which is dominated by the sum of all other sites people visit.

When you’re posting business information on social media sites, for example, that information has to live within your followers’ personal space, which is constructed by their family and real friends. Similarly, if you’re an iPhone app, your app is a small part of the total app user experience.

Fair or not, that’s life. Deal with it. Design for it.

Early Registration Must Die

The finding that iPhone apps are intermittent-use apps gives rise to many design guidelines. Here, we’ll discuss a key guideline from the initial user experience:

  • Avoid making users pass through a registration screen as the first step.

In our testing, we saw countless apps that asked users to register before having proven their worth in the slightest. This is wrong. Remember: users start out with a fairly low level of commitment to your app. Unless yours is a truly great app that offers immense value, people won’t use it enough to make registration worth their while.

Registration can certainly provide added business value and added usage convenience to your customers. But this is true only if people actually complete the registration. Sadly, if you push registration at users before they’re sufficiently convinced of your app’s value, many will simply back right out of the app and never try it again. You’ve then lost the one chance you’ll ever get at making a first impression (actually, any impression).

Cautioning against early registration is hardly new. Since 1999, a key usability guideline for e-commerce shopping carts and checkout processes has been to allow users to buy without having to register. Sites that allow “guest checkout” have much higher conversion rates than sites that require users to make up a userid and password before they’re permitted the rare privilege of forking over their money. After all, we can’t allow just anybody to shop at our site — or at least that seems to be the thinking.

Registration will cost you business on desktop websites where it’s only somewhat of a pain. In the mobile environment, every extra hoop that users must jump through causes considerablymore pain. Furthermore, users are less committed to an app they’ve just downloaded than they are to an e-commerce site where they’ve spent time browsing and adding items to a shopping cart.

When you combine

  • more pain
  • less commitment

it’s easy to see why upfront registration costs you even more lost business on mobile than on the desktop.

Example: Pizza Ordering Application

We saw many examples of too-early registration and too-burdensome screens in our iPhone testing.

Welcome screen from Pizza Hut's pizza-ordering iPhone app

Users are hit with this registration demand when all they want is to browse a selection of yummy pizzas. This was very off-putting to our test users.

The proper sequence?

  1. Show the list of basic pizzas.
  2. Let users customize their order.
  3. Show the price, along with any salient ordering info (perhaps after having users enter their ZIP code to get delivery times and such).
  4. Take the order. At this point, it’s appropriate to ask for personal info because users are now sufficiently committed.

To test the actual application, we forced users to proceed beyond this registration screen; in real use outside the lab, they would never have gone far enough to see a pizza.

Inside the app, there were some smaller interaction design problems, but the company could still double mobile pizza orders by getting rid of the upfront registration screen and asking users for their info after they’ve whetted their taste buds by showing them the pizzas.

Finally, none of the users clicked the button labeled “Not ready to order? Demo the app.”

When we tried this button (for the sake of the experiment), Pizza Hut served up the exact user experience recommended in steps 1–4 above. So, the designers know how to do it. Just not in the main UI flow 😦

Why don’t users try the demo feature? Because they don’t want a demo. They want to see the pizzas on offer. Although “just looking” is a classic shopping strategy, no one tells a department store clerk that they’re not quite ready to buy a new sweater, but they would like one demo’d. No — they enter the store, look at the sweaters (all lined up for that exact purpose), and try on the ones that most appeal to them. Only from the store’s perspective would this scenario be considered “a demo.” For the customer’s perspective, it’s simply “shopping,” and you don’t have to apply in triplicate for a permit to do so.

Although I’ve said it a million times, I apparently have to say it again to penetrate some thick skulls at Pizza Hut: Speak the user’s language in the UI.

iPhone apps are obviously a class of user interfaces, so it should come as no surprise that general UI guidelines apply, in addition to the special mobile guidelines. The difference between iPhone apps and desktop apps is that, with the former, these UI guidelines are much more critical because mobile typically implies intermittent use. Thus, the initial hurdles must be very low and easy to jump or users will never get accustomed to using your app.

Learn More

Full-day seminars on:

Presented at the annual Usability Week conference. (Different topics are presented in each city, so check your preferred city’s agenda for an exact list of seminars.)