Posts
Having embarked on this account of the Android Developer Nanodegree,
designed by Google and delivered through Udacity's platform, in March,
we've already covered a lot of skills. This part tackles mission
impossible, turning a Coder into a Designer.
I always aim for functionality first and design second, something clearly evident in my Nanodegree projects submitted thus far which satisfied just the UI essentials but also in my other unrelated-to Android-work, such as Ultimate Extract and Recover, a Win32 application and Smart Device Seeker, a Website about smart devices. So "design second" doesn't pertain just to Android applications but crosses boundaries and I guess that's something prevalent to most backend-oriented developers out there.
This has to change since design plays a big role in what breaks or makes success and, with so much competition in the Android store, producing just a functional application is not enough. This makes sense since the user's first encounter is with the 'get to know' phase that depends on the aesthetic, layout, setup and organization part of the application, taking place much earlier than the functionality assessment phase.
Thankfully, as there's patterns for everything, so there are for designing UIs and on the Android platform they're collectively known as 'Material Design'.
In addition to standardizing aesthetics with color palettes, typography, imagery and so on, Material Design also sets up a common ground for all Android apps to be built upon so that end users are able to transfer their experience of using one app to the using of another. That's why the 'Hamburger' icon, the rounded Contacts of Gmail, the flipping of pages by swiping left and right are patterns so frequently met across all Android applications.
Then again, while 'Material Design' might be the recommended way, it does not enforce strict or uncrossable boundaries, as any app is free to deviate when necessary, typically when wanting to infuse the brand's signature and that feeling of uniqueness.
The class is organized in 5 distinct units including the end project:
full article on i-programmer.info
I always aim for functionality first and design second, something clearly evident in my Nanodegree projects submitted thus far which satisfied just the UI essentials but also in my other unrelated-to Android-work, such as Ultimate Extract and Recover, a Win32 application and Smart Device Seeker, a Website about smart devices. So "design second" doesn't pertain just to Android applications but crosses boundaries and I guess that's something prevalent to most backend-oriented developers out there.
This has to change since design plays a big role in what breaks or makes success and, with so much competition in the Android store, producing just a functional application is not enough. This makes sense since the user's first encounter is with the 'get to know' phase that depends on the aesthetic, layout, setup and organization part of the application, taking place much earlier than the functionality assessment phase.
Thankfully, as there's patterns for everything, so there are for designing UIs and on the Android platform they're collectively known as 'Material Design'.
In addition to standardizing aesthetics with color palettes, typography, imagery and so on, Material Design also sets up a common ground for all Android apps to be built upon so that end users are able to transfer their experience of using one app to the using of another. That's why the 'Hamburger' icon, the rounded Contacts of Gmail, the flipping of pages by swiping left and right are patterns so frequently met across all Android applications.
Then again, while 'Material Design' might be the recommended way, it does not enforce strict or uncrossable boundaries, as any app is free to deviate when necessary, typically when wanting to infuse the brand's signature and that feeling of uniqueness.
The class is organized in 5 distinct units including the end project:
full article on i-programmer.info
Comments