I just finished reading The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind by Marvin Minsky It was a really interesting book which I really recommend. I would like to highlight this part from the first chapter “Falling in Love”
On the surface such statements seem positive; they’re all composed of superlatives. But note that there’s something strange about this: most of those phrases of positive praise use syllables like ‘un–’, ‘–less’, and ‘in-‘un-’, ‘-less’, and ‘in-’—which show that they really are negative statements describing the person who’s saying them!
—— (I can’t figure out what attracts me to her.)
I scarcely can think of anything else.
—— (Most of my mind has stopped working.)
Unbelievably Perfect. Incredible.
—— (No sensible person believes such things.)
She has a Flawless Character.
——(I’ve abandoned my critical faculties.)
There is nothing I would not do for her.
—— (I’ve forsaken most of my usual goals.)
Positive statements might hide what we really are thinking about. Did you heard in a wedding someone saying “He’s a very lucky man for marring her”? What that person probably meant was something like: “He’s lucky because I can’t understand how a woman like her could marry a man like him” or “He’s lucky because she could find a better man”
Reading about iOS7 Design Resources in the iOS Human Interface Guidelines I found a similar approach comparing iOS 7 and iOS 6. Look at the screenshot:
This looks wrong. One thing is to talk about the improvements of iOS 7 and the changes they made, and another thing is to trash your previous product. They are not doing it explicitly, but they are doing it indirectly.
- Deference. The UI helps users understand and interact with the content, but never competes with it. (The previous design competed with the content and wasn’t clear)
- Clarity. Text is legible at every size, icons are precise and lucid, adornments are subtle and appropriate, and a sharpened focus on functionality motivates the design. (Icons weren’t precise and adornments were not appropriate)
- Depth. Visual layers and realistic motion impart vitality and heighten users’ delight and understanding. (Previous design lacked vitality and was hard to understand)
These three positive statements would be just fine if they were announcing iOS 7 as a new product for the first time. In that case the listener wouldn’t have a previous model to compare with and would use the hidden negative statements on the competition. But comparing in this way your current product with the previous one is just trashing your previous work. That damages the credibility of what Apple continually claims about their products, depicting them as the best in the market. How could they say they have the best Mobile OS if they are trashing it when the next version comes out.
I think that the right thing to do should be to avoid direct comparisons between your own products and only point out the evolution, the improvement, the new features instead of sending subliminal messages to costumers saying “today we sell you gold and tomorrow we will call it shit”.
iOS 7 is here. I’ve been using it since the first beta. As far as user interfaces are effective, I don’t care too much about aesthetic, also because it’s totally subjective. What is ugly for you is beautiful for someone else. In a previous post I shared a couple of screenshots showing the difference between icons in Xcode 3.2, 4.6 and 5.0. You can see a progressive simplification of the interface. First flatting colors then flatting depth. The challenge with this design is to avoid reaching the point of maximum simplification. Let’s look at the icons in detail:
Symbols don’t have any meaning by themselves, we give meaning to symbols and icons which simply are symbols, ideograms, pictograms. If we keep the design around the first icon on the left, it’s possible to change its look without changing its meaning. It’s not a practical need, but an aesthetic one, and I understand that’s more a marketing choice than a practical one. Even if nothing really changed inside the application, a new look gives you the idea that you have a new and fresh product.
The problem with the icon on the right is that simplification reached the limit. It’s so simple, so minimalist, that a change of its design means also changing the symbol and therefore removing the meaning. Symbols are powerful and that’s why many people over the years in history tried to steal symbols and change their original meaning, like the the Nazis did with the swastika. We should avoid changing symbols too often, because that removes semantic consistency in the interface and creates confusion.
The icon in 5.0 is a simplification of the correspondent in 3.2. The icon in 4.6 is a change in the previous symbol, creating confusion and inconsistency. Then they changed it back again to the original one. The new one has very little room to evolve or change without changing the symbol. It’s the extreme simplification of the original one.
I think that iOS 7 and the OSX interface and design are great. They are simple, effective, intuitive and fun but over simplifying hides the potential risk of reaching a point where simplification cannot be accomplished anymore and the only possible choice is changing the symbol, therefore breaking consistency.
I’m curios to see if, at this point, they will be able to update the design in the future without breaking the symbolic consistency.
Xcode 4.6.x had already some sort of flat design. They removed the colors and everything was flat and grey but at least it had some sort of depth. Look at these screenshots:
Now look at the new Xcode 5.0 flat design. I don’t see an improvement. It looks like an old fashioned GUI of the 90’s. It’s even hard to understand what the icons mean. It’s so abstract that someday we’ll need an ideogram dictionary to understand what those icons mean.
Now look at a very old version of Xcode 3.2.x and tell me which one do you prefer. Honestly I don’t see an evolution in the look and design from colorful and self explanatory icons to cryptic flat ones. Flat design is not bad and it doesn’t even matter if it’s flat or not. The point here is that an user interface should be self explanatory, an icon should be worth a thousand words.
A server costs money. Not only the monthly rate you have to pay to keep it alive, also maintenance and system administration takes time, so it takes money.
If you plan to develop an app that uses a server to read/write data, be very careful and before starting anything, take into account these considerations.
- Does your server need HA (High Availability)? How to know that!? Does your application need to connect to your server to operate? In the answer is yes, you need HA! That means that your application, to do what it has to do, needs to be able to connect to the server. You can’t prevent when the user will do that and the last thing you want is a bad rating and some complain in the App Store.
HA is more expensive than conventional systems. It’s more difficult to configure and to administer. If you don’t have experience as a system administrator, and you have a great idea for an app that needs a server to work, think about partnership with a good friend with experience as sysadmin.
- Is your server able to scale? What about if your app is a great success and your current configuration is not ready for the overload? Even if your app is great it can become a great deception for the users just because your system wasn’t able to scale when it was needed. Remember, the user doesn’t know and doesn’t care about technical issues. For the user all technical explanations are just excuses. So try to avoid to be in such situation.
- Is your app a paid or free app? If it’s a paid app, think about including in the price, not only the expenses to maintain the server. Think also about the expenses for scaling! The same reason of the previous point. Maybe you need to provide 2xTimes or more the performance of your current system. That will cost you money and you have to include that expense in your app price as well. It’s important to plan for an eventual future scenario. It doesn’t depend only on how many times your app was downloaded. How will people use the app? Does it help on common repetitive daily tasks? Does it make intense network use with the server (for example a photo sharing service)? The amount of data to read/write, just text? multimedia? It’s not easy and a mistake can costs not only money but also reputation and bad ratings.
- If your app is free, well good luck! It’s a free app and the number of downloads could be huge. Who is going to pay for the server?? Ok you can use ads but remember, a paid app will cost a specific amount of money that you can control. You know exactly how much money you will get for each app and that makes prospection easier. For ad-based apps, you know you will get paid but you don’t know how much and when. If a customer buys the app, he paid for it in that very moment. Even if he’ll never use the app again, the transaction has been made and you got paid. For ad-based ones, maybe he will start using the app next month or never. So risks increase for server dependent free-apps.
- Even if your system administrator is a guru, as a developer you have to think about the possibility that your application architecture could create some constrains if time to scale comes. So the whole plan has to be discussed with your admin as well.
Just try to think about how your system will react in case of the worse and best scenario. Don’t let you go only by the enthusiasm of your idea. Keeping a cold mind, will save you from bad headaches.
A couple of months ago I found this bag in Yodobashi Camera, for readers outside Japan it’s just a huge electronic department store.
I was searching for a long time a bag that would fit my needs. That means something where I can fit enough photo gear for a daily photography geek use. And at the same time, don’t have the look of a camera-man. Bianchi is not only useful and fictional but it has also an elegant design.