Wednesday, 17 August 2016

CORNING GORILLA GLASS 5 what does up to 80% mean for the Note 7.

To quote Corning "Introducing Corning Gorilla Glass 5, a new glass solution that raises the bar for protection against drops higher than ever, surviving 1.6-meter, shoulder-height drops onto hard, rough surfaces up to 80% of the time."

They then go on to say "...That’s up to 4X better in drop failure height than competitive glasses...". They seem to be very careful to say up to in both cases.

That caveat seems rather extreme. Unfortunately the published information only has a graph with "Normalized Average Height to Failure" based on "Incremental face drop on 180 grit sandpaper". Was it this test that they used for the derivation of the up to 80%?

Are hard, rough surfaces "180 grit sandpaper". What does "surviving" mean, are there no signs of damage? I would have assumed that you would have written "no signs of damage" rather than "surviving" as to me it sounds a lot better...

Additionally when tested was it just the glass dropped (I would assume so) or was it trying to represent a mobile phone drop and did it have a 150g weight attached to it? Without being supplied the test methodology I will have to assume the former.

Again if I look at the graph there is a hint that the thickness of the glass (perhaps unsurprisingly) has an impact on the numbers. So I am assuming that 80% is for the thicker end, which appears to be 0.8mm on the only supplied graph. Unfortunately I cannot find any dimensions, but the iFixit teardown of an S7 edge (GG4) looks like it is less than 0.8mm.

So given my assumptions above. If you have watched an S7 edge drop test you will have seen that from 1.6m the screen is damaged and often cracked. This is often from one drop. Based on the graph the general rate of failure to survive is 50% higher than GG4.

So in essence it looks like the chances of damage from a 1.6m drop on a Galaxy Note 7 will be close to 100%.

So yes you will need a case to avoid needing to buy a new screen.

Which leads me on to my next question. Why make the back of the phone out of glass rather than a far more durable plastic if you are putting a plastic case on it anyway?

Additionally why curve the screen rather than provide a lip to the edge to prevent the screen impacting the floor the majority of the time?

Saturday, 28 February 2015

Black and Blue or Gold and White Dress - The emperors new clothes

I was in the office when I received a message saying, what colour is this dress?

Now I could see the glare in the top right so I though this photo was not taken under the best lighting conditions and so it would be difficult to be certain of the exact hue, but my best guess would be white and gold. I was happy to be slightly wrong, that the white was some sort of light hue, it had a purple tint, but lots of camera throw in blue or purple tints erroneously and the gold could have been anywhere from yellow to brown.

Apparently I am wrong, the dress is blue and black. Now this would not bother me, but apparently lots of people, perhaps the majority see it as black and blue, where as some see it as white and gold.

So I took different segments of the dress in isolation and performed and analysis of the colour composition of each portion. In HSV terms this comes up with an average colour of bright drab violet (RGB  B9,AD,C4)  and medium faded orange (RGB 7A,63,48). So the image of the dress is correctly very light purple and gold. It is certainly not black and blue as there are huge amounts of orange in the image the darkest part of the "black" portion is (RGB 42,42,42) which I believe most people would call grey, and that is the absolute darkest part in the shadow of the left side of the dress!

It is very interesting that peoples optical filters can have such a dramatic effect. So if you see white and gold you are largely correctly identifying the colours out of the context, however, if you are seeing black and blue you are somehow adjusting to the correct context of the photo's horrific white balance.

Interestingly I have read that some people have changed their minds after looking at the photo on a different occasion, I wonder what is required to achieve switching. I have tried adjusting my focal point, but the best I can manage is light purple and dark orange which is roughly what the pixels are.

Thursday, 15 January 2015

Hypotheses are for testing, but assumption is the mother of disaster

If I were to ask what is the most important element to being a good programmer I would say the ability to avoid making assumptions and instead make hypotheses that can be tested. Knowing you are right because you have data to back it up will allow projects to remain on track. Ploughing on based on guess work and things a colleague told you once (without providing you with data & methodology to back up these statements) will likely lead to ruin.

I does not matter how long someone is programming it is always possible that someone heard something once, took it as gospel and never tested it to make sure it was true. I encountered this with a couple of colleagues and an SQL query. The SQL query was built from a ORM-like query generator and included the syntax WHERE 1=1. Both my manager and a senior developer stated, "well that is the problem WHERE 1=1 will always cause a full table scan rather than use indexes".

When I looked at the same query I thought that the table may be missing indexes and the  GROUP BY clause was potentially causing the problem, however, rather than assuming I was right I set about testing variants of the query.

My testing was in MySQL so I was employing SQL_NO_CACHE in my select statements to make sure the behaviour was not effected by query caching. This command is vital in any query optimisation testing. 

My testing proved that WHERE 1=1 has no discernible effect on query perform and does not prevent the query from caching. Of course removing it would be a few less characters to be sent over wire, read and parsed by the engine, but it certainly does not trigger a full table scan. 

WHERE 1=1 is an easy way of setting up where clauses so that you can just concatenate AND condition, without having to remove the first conditions AND. It is even useful for testing your own queries in a tool like MySQL Workbench you can comment out various ANDs and not have to worry about the syntax breaking.

Reading the MySQL documentation also makes it clear that clauses like 1=1 are removed by the constant condition removal portion of the WHERE clause optimisation. There may be some SQL variant that does not manage to optimise this condition away but it is certainly none of the major vendors I have worked with over the last 10 years.

Testing illustrated that the GROUP BY clauses caused the biggest performance issue, there were also some other optimisations available by removing unnecessary JOINs. I was slightly surprised that the ORDER BY on an unindexed column did not cause any real impact. Please do not be fooled by myths, dig into the code and test for yourself. Testing that 1=1 does not impact performance takes a few seconds if you have a MySQL database running, going down the root of assuming that it is a problem can waste hours "fixing" code for no benefit.

Through testing though you can come up with some interesting discoveries, such as 

count(DISTINCT id) FROM `table`

is substantially slower than 

count(*) FROM `table`

even though id is a unique primary key column. The system I was using was automatically constructing the first query, which on very large tables was able to take 1-2 seconds, whereas the second always came back in less than 0.001 and provided the same result. 

However, as I said don't take my word for it, form a hypothesis by all means, but never make assumptions, hypotheses are always tested, but assumption is the mother of disaster.

Sunday, 14 December 2014

User Interface Usability Checklist Part 1

User interfaces are changing quickly, and it can be default to keep up with new designs and trends. The smaller the team the more corners are cut to try and get the product to market. Lots of people advocate the creating and releasing the minimum viable product. This is fine, but companies try to do so without the minimum viable staff level.

Creating a great user interface takes good design, user testing and lots of iteration. Unfortunately user testing is often the first "cost" that is abandoned. The next is the available design time. So when you become incredibly constrained then making good design choices becomes your only course to prevent a horrible mess at the end of the project. I have created a usability check list of common design mistakes. I have seen all of these mistakes in projects from the most expensive to the most basic free apps, and if you can avoid all of them you are well on the way to producing a high quality application.

User Interface Usability Checklist

 1: Using checkboxes where you should use radio buttons

 Checkboxes imply that you can select more than one item, radio buttons indicate that only a single option from the list is available. Sadly too many interfaces have single selecting checkboxes. Radio buttons are also often not the best option, sometimes icons or hyperlinks are better interaction options. I have generally found that radio buttons are one of the least understood generic UI elements, only multi-select lists cause more confusion/

2: Using a checkbox out of enable/disable context

It is important to take care in making sure your checkbox is an obvious boolean state switch, depending on the wording it can be unclear what occurs when you unselect the checkbox. e.g. a checkbox with the label Always print receipt slip. When it is on you know what will occur, but with it off will it never print a receipt or sometimes print a receipt? Remove the ambiguity by renaming the checkbox or provide a radio button with all of the options available.

3: Using command buttons as toggles

Toggling states tends to cause confusion and mistakes, more so when you are using a magically re-naming button.

4: Using tabs as radio buttons

This can cause confusion because the standard use of tabs is for them to just break up areas of the same object into different visual regions of information. If you use them as a data manipulation method to achieve the same type of functionality as a radio button this will confuse users as they will be unsure of what will happen with the "hidden" data, is it saved to the system or not?

5: Too many tabs

Determining if an interface has too many tabs is generally down to individual use cases, however, I have a basic rules of thumb. If you require 5 tabs to display your interface it is important to think is this the best way of presenting the data. More than 5 tabs starts implying that you should reconsider how the interface is displayed. Of course this can be broken, but only with careful consideration.

6: Using input controls for display only

Sometimes people use disabled input fields to display data that cannot be edited. Disabled fields imply there is a way of unlocking them for access, if this is not the case then disabled fields should not be used. However, sometimes people take this one step further and use input fields for display text. input fields should only be used if data entry is a possibility.

7: Always using text fields when data entry needs to be constrained

HTML5 introduced a number of field types, such as email. It is important to use these rather than a generic text field with client and/or server validation (or worst still no validation), especially in the mobile context. Try typing an email address in a standard textbox on a mobile device and watch the spelling correction mess up your entry. Highly frustrating for any end user I am sure you will agree.

8: Disappearing menu items

While contextual presentation of information can be useful in aiding the understanding and interaction flows of an application, it can also hide the available actions and cause confusion in long term users who memorise the application's menu structure. Microsoft XP's start menu is a prime example of this with its short and long menus.

9: Intolerant data fields

I am sure many people have experienced the following problems.

  • Your password must be between 8-10 characters and must not contain $*!. It can be very frustrating trying to create a memorable password that meets those constraints.
  • Enter your phone number, but I'm not going to tell you if I will accept with or without international code until you fail validation as the end of the form.
  • That post code you just used which works on ever other website is not a valid post code. A common mistake is needing to type in post codes in a specific format. XXXYYYY is invalid but XXX YYYY is fine... 

Try to be intelligent in validation so that the user does not get told they are wrong when the computer can easily check to see if a minor reformatting to match the database requirements is needed.

10: No defaults for input fields

Providing defaults can really speed up the interaction with your systems design. Consideration should be placed into supplying defaults.

11: Poor defaults

Defaults are important in allow appropriate customisation of your application, while allowing users to quickly access and use your product. Poor defaults can make your application look rubbish and make people think that the desired behaviour does not exist in your application. Excel's default behaviour regularly annoys me and has caused countless support issues in many companies. If you type in a number such as a phone number it will happy cut off leading zeros and stop the number from having its original meaning. I do not understand this default behaviour, people do not just enter leading zeros for fun, they have a purpose. This is just one of many default behaviours which are undesirably in Excel.

12: Negative checkboxes

Yes there are plenty of websites that have negative checkboxes, check this box to not receive a torrent of useless span from us, they do this to try and trick people into checking the box when they do not want to. Use positive checkboxes to help make sure your users are making the correct decisions rather than checking the box by mistake.

13: Check the titles are right

We have tabbed browsers, multi-window applications, try to identify the tab or window by putting something a little more useful than the domain or application name in the Window / Brower title information.

14: Don't use self-links

It can cause people to consider that they might get directed to a different version of the page you are on. If the page changes regularly then a self link might seem a simple solution to get the page refresh, however, if possible aim for a more dynamically updating page to assist the user in understanding that there is new/changed content in relation to the context of the page.

15: Competing search boxes

Multiple search boxes on a page can often cause problems, using the wrong one can at a minimum make you have to go back, or at worse think there is no information available for a search when there is and so make incorrect decisions from this.

16: Poor search results

Searching is not a simple matter. Most people have no experienced Google and realise that it is possible to have relevance ranked, spelling corrected, sentence contextual returned results. As a developer we realise it is not that simple to achieve a search as good as Google, but often you will have the benefit of a less varied set of data to search over than every web page in the world and so can create a pretty good search rather than just a basic exact text match.

17: Inconsistent terminology

This is incredibly common, and can cause failed interaction very easily. Many terms get switched around interchangeably; user, administrator, client, customer. Try to use just one term depending on what you are referring to, and importantly make sure the whole company agrees, without this agreement the multiplicity of terms will slip into the product.

18: TL;DR (too long didn't read)

Try to make every word count. Too many words can introduce ambiguity, so always try to be short and concise. This requires careful attention and revisiting of old designs to make sure you adhere to this principle.

19: Speaking the language of your audience

Your language should be directed to your specific audience. As a user interface designer you probably know the term "radio button" but if your audience is not part of the programming community they probably do not. One of my favourite examples of this is when a friend of mine was dealing with a support call and he said over the phone "press the windows key". The response was that this did not do anything. As he was not progressing on the phone he went to the person's desk to see this for himself. He found out that "press the windows key" had been interpreted as "press the key that is tapped to the window". Not many people know what the windows key is despite every Microsoft based computer keyboard having one for ages.

20: Vague or misleading error messages

First on the programming cost saving list is error handling. It is sad but true, but clear error messages directing the end user in what they can do to fix the problem is essential. It is very frustrating to get an error message and have no real idea what to do next. What can be worse is a poorly programmed error which suggests the cause is one element, when in fact it is another. These are much harder to deal with and tend to only be picked up if you have a good test team with a good test plan.

Tuesday, 4 November 2014

Why should you use PDO?

I was recently asked if I could think of any good questions to ask a PHP programmer in an interview. Obviously this got me curious as to what Google might return for this query.

I noticed that a few people recommended asking questions in relation to PDO. All people suggesting questions on PDO were forming questions where the answer essentially was that PDO should be implemented so that switching database is easy/easier.

I have worked on numerous commercial products for a number of years and none of these have ever switched database.

How common a change it is to switch database on a project? I can't imagine the % is very high, although I have not been able to find any figures on this. Additionally of the systems that require switching I suspect they are probably moving from an archaic language / database which does not support the system they are moving to, and so you are largely doing a complete rewrite anyway. Will SuperSQL++ 2040 support your PDO queries from PHP 5.6? Perhaps a database abstraction layer is of minimal real benefit?

There are only 3 real reasons for switching database that I can think of:

Proprietary features
If you want to use features that only exist in a specific database then generics are not the answer, use of proprietary features implies PDO is not useful in this case.

A reasonable cause for switching DB vendor, but how often will payment terms be altered over the lifetime of a product? Is switching worthwhile vs the cost of testing, development and deployment, even if you did have PDO implemented?

If the DB is no longer supported then sticking to it becomes a significant business risk, however, if you are using a system that is no longer supported and PDO would have been beneficial then you really did back the wrong horse. Most databases have been around for many years and I doubt any of the PDO driver ones are going away soon.

So does PDO bring any other benefits?

Well it does have named prepared statements. These are superior to MySQLi's "?" sequencial parameters.

Then there is client side prepared statements, this can actually lead to improved performance in PDO statements over using MySQLi.

What are the Costs?

Implementing PDO in terms of coding does not really add any noticeable cost, however, there are resource costs which should be considered. There is a small overhead on every PDO command versus using proprietary extensions. During my testing I have found this overhead to be 2-10% depending on the nature of the query. This essentially translates to a 2-10% increased database server resource cost. Some examples can show PDO is faster, but I suspect that most people would agree that overall in an application there is a small percentage loss in performance.

Perhaps more significantly you can't use proprietary features. There are minor inconviences like not having num_rows() for select statements. 

Then there are major issues like not being able to perform asynchronous queries. Depending on your use case you can see up to 50% performance increases performing asynchronous MySQLi queries.

So who wins?

While I think there are always more important things to do than change database easily having the option is always a benefit, even if it is a very small one. I would think that a 2% performance overhead would be enough to displace this benefit, but when you consider that you might be turning your nose up at 50% performance increases then PDO quickly becomes the loser.

I am curious if there is any evidence to the contrary to my believe that switching DB is uncommon, and perhaps more importantly if I have missed any other benefits that using PDO may have over MySQLi.

Tuesday, 5 August 2014

More weird adventures in Cache SQL - SOLVED

Well made a new interesting discovery today. Combining TOP with ORDER BY can severely slow down a query.

I was looking into a slow query which was taking around 10 seconds to return 69 results. It was getting the "TOP 100" from a specific date range and then ordering by ID descending. It was fascinating to me to discover that removing the TOP 100 returned the results in 0.005 seconds. Removing the ORDER BY instead of the TOP 100 also resulted in again producing the results in 0.005 seconds.

So the moral of the story is don't use TOP and ORDER BY if you want your results back quickly.

I have no idea why this kills performance right now, but it is perhaps even more interesting that even though the query TOP 100 ORDER BY ID ASC results in the same set of results as TOP 100 without an ORDER BY command, it takes 8.8 seconds rather than 0.005 seconds. There are definitely some huge optimisations available in respect to these queries.


Well after reporting this to Intersystems I was directed to %NOTOPOPT query optimisation method. It states that without this TOP is optimised for first row retrieval rather than the full result set. This implies to me that a TOP 1 should be faster without %NOTOPOPT and that returning more than 1 has the chance to be faster with it. However, when I was testing across various queries whether it was TOP 1 or TOP 100 with an ORDER BY I always retrieved the results much faster with %NOTOPOPT. If you have a TOP query running slowly I recommend testing with this optimisation option, as you may see much better performance as I did.

Saturday, 2 August 2014

So which is the best mobile keyboard 2014

PhotographerCindy J Grady
I have been lucky enough to experienced using keyboards on iOS, Android and Windows Phone (8 and 8.1) which has really shown me how important a good input method is in the mobile experience.

Each keyboard has unique features which makes choosing the best keyboard a bit of a struggle. Until recently I had completely dismissed iOS keyboard for the following reasons

1. 4" display means that the keys are harder to press accurately
2. Selecting & deleting words is trickier than both Android and Windows Phone not just due to the smaller target area, but also the implementation requires a "long press" to activate the magnifying glass to achieve accurate cursor location.
3. Lack of swype / shape writing style input.

While options 1 and 2 were of just minor inconvenience option 3 is a major issue.

Swyping / Shape writing

There are three great features of shape writing

1. It is a much faster input method on the whole than key pressing as demonstrated by the numerous keyboards of this style achieving Guiness World Records.

2. It allows a more generalised area of keypress which is of great advantage on a smaller screen, or even allows you to cope with a smaller keyboard on a larger screen giving the benefit of seeing more of what you have typed so far.

3. The input can be done at full speed with a single digit. Rather than the common double thumb entry for iOS to generate speed shape style writing can be performed one handed.

What Does iOS have up its sleeve

Historical Autocorrect

Obviously we have all had a laugh at damn you autocorrect and probably have received a couple of weird messages due to autocorrection errors. However, autocorrection is pretty clever, but on iOS it actually tracks back up to 4 words based on what you are entering and can correct the 4th word. Contextually autocorrecting 4 words back will tend to help weed out a huge number of errors, and is certainly a clever feature to have,

Cross Platform Support

Apple has always integrated its devices well, anyone with an iPad, Apple TV and Mac will know that so many things transfer relatively seamlessly across without the need to be tech-savvy. iMessages synchronising with your devices is a good example of this. Well the iOS keyboard has another one of these clever features, simply create keyboard macros on your Mac and they are straight away available on your iPhone and iPad.

While the stock Android keyboard offers keyboard macros (as well as some less popular alternatives) these macros are limited in length. If for example you had a long HTML sign off signature you were particularly proud of this would probably be too big for the dictionary. However, Kii keyboard will store macros that are large enough, but the dictionary does not sync across devices, so you need to re-enter any macros on all devices you want to use.

Is this enough?

I can understand that these features can be sufficient to turn the tide for some, but shape writing is such a massive time saver for 99% of the text I input that synced macros is simply not important enough. So sadly iOS keyboard is ruled out of the running, leaving Google Keyboard, Windows 8.1, Swype, Swiftkey, SlideIT & Kii.

Google Keyboard

Google have built a very good basic keyboard. It is fast and responsive, even on lower end devices, which is not true of some of the other options. I have found it to be quite accurate and fast, and is my recommendation if you have a slower device as there is nothing quite as frustrating as a sluggish keyboard response.


SwiftKey recently became free, which is quite a bonus in its favour. The next work predictions are quite scary, it makes you realise just how much you repeat yourself and various phrases. I find this aspect a bit creepy almost as if it knows what you are about to say. It does however, inspire me to try and vary my language a bit more almost like a challenge to say, "No you are wrong! I was actually going to use a 16th century old English word, take that dictionary!"

This is probably the second best keyboard for non-shape writing input, with iOS beating it and Windows 8.1 coming in a very close third. I know that some people cannot get on with shape writing and if you are one of those then SwiftKey is probably your best bet on Android.#


I will be brief about SlideIT to save you sometime, the predictions are not a good as the other options, it does seem to be relatively low on resources, but overall the other options including the stock keyboard are superior.


Kii tries to be a combination of SwiftKey and Swype, the options available are staggering it definitely has the best options for personalisation. I have found that its predictions are good, but not the best and so I am not placing it at the top, however, there are some relatively unique features such as dual language input to allow seemless corrections for bi-lingual users (no dictionary switching required) and the ability to customise the size and placement of the keyboard. Kii is certainly worth a try and you may find that the personalisation options make it the best option for you.


Swype continues to offer the best predictions and best corrections. By comparison I rarely find the need to go back and make corrections. It is nearly perfect, but there are a couple of let downs. I always turn off Dragon Speak as I find it is very bad at managing to identify anything I say, this means there is no quite way of activating Google voice for dictation. This is a minor inconvience for me, but I could see others finding it a deal breaker. I would also love to be able to customise symbol key placement and perhaps create gestures like Kii offers. It does over some very useful customisation in the form of keyboard size and placement, which can allow you to perform one handed typing on a much larger device. I have found it possible to shape write one handed on a Nexus 7 without issue and with many devices pushing 6" it could be of great benefit to many.

Fundamentally the accuracy and the best autocorrection leads me to choose Swype as the best Android Keyboard, but is it the best keyboard of all?

Windows 8.1

Windows 8 has very good correction algorithms for corrections making it one of the best keyboards for typing, but 8.1 introduced shape writing. The accuracy of the shape writing is similar to that of Swype, leading to rarely requiring post writing corrections. It also has a couple of unique features, you can for example add or remove capitalisation from an already complete word just by placing the cursor in it and pressing shift. Additionally the voice recognition is of a similar quality to that of Google's and with this minor addition I would rate the keyboard as a fraction above Swype's offering, making the Windows 8.1 keyboard the best mobile keyboard. Sadly it is only available on Windows Phone, and the Windows Phone platform while great in many ways is not the equal of Android right now.

iOS 8

One of the features that I am really interested in is iOS 8's opening up of the keyboards. I am really curious how many people will switch away to Swype or Swift key.