Is Apple confused about the design of iOS 7?

By mOrPhie on Thursday 13 June 2013 15:36 - Comments (17)
Category: techrelated, Views: 9.485

This is a screenshot of iOS 7 on the home page of apple.com:

http://tweakers.net/ext/f/ybTZ3AoESW7tcYiOoUNLXAtw/full.png

This is a screenshot of iOS 7 on the landing page of iOS 7:

http://tweakers.net/ext/f/3FkQnGAO3SOfBD5fKpPZTJ0r/full.png

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:

http://tweakers.net/ext/f/NNHNTBEVBumsoH2RxYA9tpiR/full.png

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:

http://tweakers.net/ext/f/nYBJNbeunWrBkTkvDvMvflNI/full.png

Some more examples. See it in action. Without drop shadows:
http://tweakers.net/ext/f/et8wAi4gDUI5oR8VP9FnwUtL/full.png

While talking about design, with drop shadows:
http://tweakers.net/ext/f/Z3hfrs2Y2ZQFIRPt89hIP1sb/full.png

During keynote presentation, with drop shadows:
http://tweakers.net/ext/f/dAjemgCArp4xy1yUR1myXtXm/full.png

During keynote demo, without drop shadows?
http://tweakers.net/ext/f/evxhHj72wrF14rnIkkwvYvI2/full.png

Is is me or is Apple confused about the design of iOS 7? Considering all the details, Apple?

Easy Access

By mOrPhie on Tuesday 5 October 2010 10:09 - Comments (6)
Categories: software engineering, techrelated, Views: 4.222

iOS 4, iPhone's OS, added the feature to put applications in a folder. After I upgraded, I immediately began organizing my apps. One of the folders I created was the "often used" folder. After two days of use I realized that this wasn't such a great choice, because now I had to open up the folder before I was able to start the app. Right next to the folder are some apps that I don't use at all. I didn’t bother putting them in a folder. But now I know: that should have been the other way around.

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.

Try something different

By mOrPhie on Thursday 30 September 2010 10:45 - Comments (10)
Categories: software engineering, techrelated, Views: 8.210

Sometimes a software developer makes a fundamental decision without even realizing it. A C# developer almost always chooses MS SQL Server as the preferred database. What does that decision imply? The data is stored in a relational manner. The data isn’t easily transferable. The model is fixed. You need a license. To install the software, you need to install a SQL Server. The database must be maintained in some sort of way, ect... The implications of such a decision are so big; only an architect should make that decision, shouldn’t he? And he should be very explicit about it.

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”.

http://twitter-badges.s3.amazonaws.com/follow_me-a.png

Subconscious prototyping

By mOrPhie on Tuesday 21 September 2010 18:30 - Comments (3)
Categories: software engineering, techrelated, Views: 2.771

If your software development is slow and painful and productivity drops every day, consider this: Are you fixing the problems caused by development that was actually prototyping because you didn’t understand the problem you needed to solve just yet? If this is the case: start over and use your new found knowledge to create a better base and dodge the productivity problems you faced earlier.

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.

http://twitter-badges.s3.amazonaws.com/follow_me-a.png

The Software Quality Poem

By mOrPhie on Tuesday 14 September 2010 22:49 - Comments (10)
Categories: business, software engineering, techrelated, Views: 5.083

Bugs, faults, errors and defects
They are all the same to me
Please ignore the name
Value the severity

Feature popularity
Specification compliancy
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

:-)

http://twitter-badges.s3.amazonaws.com/follow_me-a.png