This is a screenshot of iOS 7 on the landing page of iOS 7:
Notice anything different? Well, the first screenshot shows a drop shadow behind every icon (apart from those in the quick launch), while the second screenshot doesn't include these shadows. The difference is important, because the drop shadows result in a less flatter look and more contrast.
The same thing applies to the wallpaper. In the "iOS 7 video" on Apple's website, the wallpaper differs from the other wallpapers. In the video, the wallpaper is much darker, but without drop shadows:
And when you install the beta, you are presented a much brighter wallpaper that lacks any contrast at all, making it less pleasant to look at:
Some more examples. See it in action. Without drop shadows:
While talking about design, with drop shadows:
During keynote presentation, with drop shadows:
During keynote demo, without drop shadows?
Is is me or is Apple confused about the design of iOS 7? Considering all the details, Apple?
As a software developer, let's learn from this. There are two lessons:
1) Often used functionality should be easy to access. Rarely used functionality doesn't have to be easily accessed so it can make room for often used functionality.
2) Users can make up their mind, because they started to use the product.
The reality is that in most C# projects the choice of RDBMS isn’t a logical decision, but based on what the team is used to. That concerns me. Think about it. What if SQLite would fit my needs just perfectly? That would save me the time of installing the server, I am able to copy the database as a file and it is free. I’m not saying you should use SQLite in all of your projects. I am saying you should consider alternatives and ask yourself why you should use it and what part of your software problem it fixes. Maybe XML could fit your needs. Maybe you don’t need a relational database and a document-based database like MongoDB is something to consider.
I’m sure you can imagine this can be applied to more than just databases. The language, the framework, the runtime, the tooling, the software architecture… Surprise yourself and maybe, just maybe you’ll find yourself doing an IronPython project with Django, the .NET DLR, persisting your data in MongoDB. Although I highly doubt that you’ll come up with that combination through a logical decision process , it helps you think about the “way to go”.
What happens here is what I call “subconscious prototyping”. If you are faced with a project in which specs are vague and development is somewhat unstructured, you might find yourself developing software, while solving a problem at the same time. Those who are able of doing just that without problems are a very rare breed. Or, of course, the problem to solve is a very simple one.
Even better is to understand the problem and its solution before you start typing away. So, the lessons learned: 1) Nominate problems and concepts that are hard to understand for prototyping, detailed design and design reviews. 2) If you still get stuck, notice “subconscious prototyping” as soon as possible and consider re-planning before it’s too late.
This might sound obvious to you, but some projects need this reminder every now and then.
They are all the same to me
Please ignore the name
Value the severity
And customer satisfactory
All define the priority
Unit testing, code review
Architecture and design
Prevent a list of bugs to grow
And make the software shine
So, if you find yourself
Fixing a bug or three
Think of this poem before moving on
And improve software quality