If you’re NOT developing for BlackBerry 10 platform perhaps your users are complaining apps running too slow.
Speedy Q10
On BlackBerry 10 you have to think ahead because apps are running so incredible fast – esp. using Keyboard devices like Q10 – that you run into situations not thinking about on a ‘normal’ smartphone.
You speed up users workflow using shortcuts:
E → 12 → enter
and you’re done with:
- tip on E to edit the quantity of an order position
- new page opens
- curser already in quantity field
- keyboard switched to numeric mode
- type 12 as new quantity
- tip on ENTER key
- new quantity saved
- page closed
- list summary recalculated
this is an intuitive and fast way to work with business apps on a smartphone.
And sometimes it can be too fast 
DeleteAction on Z10 (Touch)
As a good citizen of Cascades UI design guidelines you’re using a special ActionItem to delete a row in a list or so:
DeleteActionItem {
id: deletePositionAction
title: qsTr("Delete Position") + Retranslate.onLanguageChanged
ActionBar.placement: ActionBarPlacement.InOverflow
onTriggered: {
// delete the position
}
}
Delete actions are always placed at the bottom of your menu. Here’s how it looks like on a Touch Device:
To get something deleted you have to do a first tap to get the menu:
then you have to tap on the delete action:
there’s enough time to decide what to do and you have to tap directly on the delete action, so normaly you don’t ask the user “do you really want to delete this item ?”
DeleteAction on Q10 (Keyboard)
Now on Q10 the situation is different using shortcuts. You must know that Cascades automatically maps some actions to keys – and this will work in all applications without the need for you to code this by yourself. If a user on the Q10 taps on the menu, then the keyboard shortcuts become visible:
the DEL – key is mapped to the Delete Action. automatically.
the E – key is mapped to the Edit Quantity Action by me as a SystemShortcut:
SystemShortcut {
type: SystemShortcuts.Edit
}
Because I want to edit something, I’m using one of the SystemShortcuts instead of my own custom ShortCuts.
Now we enter the dangerous area
If the user tips on the DEL key here, the delete action will be triggered. without any warning. perhaps it was the wrong key and the user wanted to type P or ENTER.
You have to find a way to avoid this.
Undo – the user-friendly solution
Normaly converting apps from Touch (Z10) to Keyboard (Q10) is easy and soon done – but you should carefully test your app on Q10 to find hidden traps.
What can you do to avoid deleting a record by accident ? the easiest way would be to insert a yes/no SystemDialog and always ask if the record should be deleted. But now you’re breaking the users workflow. not so good.
here’s one solution:
- on Z10 use it as before
- on Q10 add an Undo function
Undo must be implemented a way not breaking users flow. There is a UI control you can use for this: Cascades SystemToast: a small popup window going away after a short time. And here’s my solution:
If DeleteAction is triggered, test if you’re on a keyboard device and if so, don’t execute the delete logic. Instead of this I’m changing the Icon of the list row and bring up a Toast with the same icon and some text to inform the user.
SystemToast {
id: deleteToast
body: qsTr("Position will be deleted") + Retranslate.onLanguageChanged
icon: "asset:///images/position_to_be_deleted_small.png"
position: SystemUiPosition.BottomCenter
button.label: qsTr("Undo")
onFinished: {
if(deleteToast.orderId > 0){
if (value == SystemUiResult.ButtonSelection) {
// UNDO clicked - revert to normal Icon in this case
} else {
// do your DELETE stuff
}
}
}
}
Now it’s up to the user:
- if DEL was done by accident click on the Undo button an all will change back to normal
- if DEL is what user wants to do simply follow the workflow – ther Toast will disappear automatically
From my POV this is an elegant way to solve this situation: user has full control and workflow not broken 
The Video
here’s a short video where you can see how it works before and after:
Some tips for developers implementing such a solution
Toasts will go away after a short time, but you cannot set this delay. Toasts with a button will remain on screen until user does some work on UI, which will start the countdown until Toast disappears. In some situations this is too long for me, so I want to dismiss the Toast per ex. if user triggers another action, clicks the back button or something else.
cancel() on a Toast will stop and hide the toast immediately. cool. or not ? If Toast is canceled means, user has NOT clicked the Undo Button, so the data can be deleted.
But cancel() doesn’t trigger the onFinshed() at Toast. with a little trick this will work:
add a boolean property ‘killed’ to the Toast, fire this if you cancel() the Toast and now onKilled() at the Toast can execute the same delete- businesslogic as onFinished() from TimeOut.
I will publish some code on this later and will also add this pattern to my workshops on Cascades, because you’ll need this all the time in business apps.
Have fun with Q10
If you need an App: I’m developing quality BlackBerry10 APPS for customers around the world
If you want to write such kind of apps by yourself: You can book a training (in german or english)
ekke
