Getting my hands on Mailbox for Mac


Mailbox_mac_snoozeMailbox_mac_snooze

Mailbox_mac_snooze


Mailbox_mac_composeMailbox_mac_compose

Mailbox_mac_compose

Finally, a mail client that I enjoy working with. Apple and GMail users have long suffered on the mac, but no more. The guys at Dropbox finally released a beta version of Mailbox for Mac, extending their product offering from the iOS platform, famous for it’s sleek gesture-packed features, allowing you to swipe to archive, swipe to postpone to later. The desktop sibling has managed to inherit all the fun of the mobile version, and whilst it’s still heavily in beta, I have switched over to using it full-time. Most importantly, this client app is a huge proponent of zero-email, the concept of ensuring optimal productivity by reducing your inbox to zero, and delegating deferrable actions to a later stage.

Sporting a clean interface, for those of you whom especially used the mobile version feel immediately at home. On the left-panel you get all your essential mailbox folders, including the Later and Archive folders, where your mail gets delegated to when you swipe them from your inbox.  When you get an email, you can either choose to read it, after which you can archive it, or choose to action it for later.

The illustration above shows the various options you have, with macro buttons for later tonightnext week, someday to mention a few, as well as something new and exciting,  mobile, which allows you to defer action to the mobile version of the app, and vice-versa. Think of this as when you are reading an email on your desktop, and need to rush to a meeting, so you can push it to your phone so you can respond to it conveniently.

iOS 8 will have something similar for it’s native mail client, but Mailbox decided to beat Apple to the punch, by a few months. Composing emails are just as elegant, and since Mailbox is a dropbox product, you can seamlessly attach dropbox files to your email, as a link and saving you precious space in your sent folder. Mailbox have also announced on their blog they are supporting Drafts, between iOS and desktop, which will become an important aspect when dealing with cross-platform use of the app.

You can start emailing on one platform and finalizing it on the other, something I must admit Apple have so far failed to wow me with when using their native client. I will continue to play around with it and look with keen interest as the beta develops. The beta is closed, and required a betacoin, but you can apply for an invitation by clicking here. I have also offered three free betacoins for my dedicated readers, for the first lucky three:

http://cl.ly/image/0a3I1U3c1z3R/coin621611.gif

http://cl.ly/image/3w192o0g433w/coin606166.gif

http://cl.ly/image/0L1e2x381c2s/coin606167.gif

Personas and why they are important

A persona is a measurement model, which started to take off in the 90s, as a way of marketers to be able to tangible depict a person, not a real person but rather “synthesized from observations of many people”.

Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters,

Personas for me today, when working on mobile projects, allow us to understand the range of customers that would use our completed app, and in an iterative agile methodology, identifying the right personas (especially in the early stages) allows for concept validation and re-validation, the ability to test theories and ensure it meets the target market.

What are personas?

 

Conceptually, a persona is a one-page document that summarises research trends and patterns of a particular targeted market segment, as a person, with a fundamental emphasis on understanding the person.

 

 

Take a look at a great article by Smashing magazine which goes into great detail on Personas:
A Closer Look At Personas: What They Are And How They Work (Part 1) | Smashing Magazine

JIRA Smart Commit Cheatsheet

If your development workflow includes the use of Atlassian JIRA project task management tool, and you have a code repository, such as github , you can make use of what Atlassian calls it, smart commits, as a way of processing JIRA issues with commit messagesIt makes working with JIRA a lot easier, as a developer, whereby when you commit your code changes, adding smart commit tags allows you to interact with JIRA, without having to even visit your JIRA installation site. Makes your Project Manager happy, and your live as a developer easy. I’ve created a cheat sheet with the essential commands, to get you started, which you can download below:

Download cheat sheet

Be sure to also check out Atlassian’s documentation on smart commits.

How to Get Started With Design Sprints

Smashing Magazine today talks in their piece, Off To The Races: Getting Started With Design Sprints about Iterative Design, or rather, Design Sprints. This hypothesis follows in the footsteps of industrial development best practices, which has for a long time now had monopoly in working in an agile sprint environment. Why not give Design it’s own Sprint board?  So let’s get started on How to Get Started With Design Sprints… colored-pencils-374771_640 Benefits of allowing your designers into the Sprint-party ensures that initial product development is not dependent and tightly-coupled to the design direction, whilst allowing the design team to pivot design based on iterative user feedback, making amendments and adjusting in an agile-way according to market changes and other market needs.
 

 

(Source: SmashingMagazine)

 

Setting up a Design sprint, rather than fully defined up-front, breaking tasks into 1–3 week sprints with an emphasis of solving specific design problems. The author proposes 6 steps in the sprint:

  1. Research : Capture insights using empathy maps to capture findings, recording what users said and did, and figure out what users think and feel.
  2. Analysis : Analyse what was found, with each person presenting his or her findings, along with discussions and brainstorming.
  3. Ideation : Having created a priorised list of problem statements, the team can focus on generating solution ideas (this is an iterative process in itself), allowing the team to come up with clear design directions, in either low or high fidelity wireframes/sketches.
  4. Prototyping : The final few days of the sprint is spent detailing the design in a fidelity level allowing for validation of design direction. The author prompts people to think of prototypes as as “visual way to ask questions”.
  5. Validation : The last step is of course to validate, and just as research was done by the team, in parallel, team members can also do the testing with several users.

Finally, the author presents a concise list of benefits to implementing Design Sprints:

  • Momentum : Allowing for rapid shift from one problem to the next.
  • Waste minimisation : Reduced documentation and increased collaboration, an optimised flow that reduces activities that do not contribute to development
  • Enchanced Design conception : Comparmentalising proiblems into smaller ones, designers can explore many different ideas with more focus and thoughtfulness.
  • Innovation encourager : Sprints encourage exploration and risk-taking, a hotbed for innovations to be conceptualised in the product development space. I am a bit advocate of this method, and would encourage teams to look into a more holistic agile approach, beyond the confines of just development.

Source: Off To The Races: Getting Started With Design Sprints

Quick tip on working with iOS Auto Layout by code

icon512.png 512×512 pixels

A quick tip for those of you working with iOS Auto-Layout in code. During your development, you can test whether a particular view is sufficiently constrained/specified, by asking hasAmbiguousLayout
By using in in NSLog, you can query the view’s constraint satisfaction as follows:

NSLog(@”View <%@:0x%0x> has ambiguous layout? %@”, self.aView.description, self.aView.hasAmbiguousLayout);

NSView Reference

hasAmbiguousLayout
Returns whether the constraints impacting the layout of the view incompletely specify the location of the view.

  • (BOOL)hasAmbiguousLayout
    Return Value
    YES if the view’s location is incompletely specified, NO otherwise.

Discussion
This method checks to see if there is any other frame the view could have that would also satisfy the constraints on the view. This is an expensive operation and is not run as part of the normal layout process, but can be useful when debugging whether a given interface has been specified with a sufficient number of constraints to ensure consistent layout. This method is automatically invoked when a window has been told to visualize constraints with the visualizeConstraints: method.

This method should only be used for debugging constraint-based layout. No application should ship with calls to this method as part of its operation.

Availability
Available in OS X v10.7 and later.
See Also
– exerciseAmbiguityInLayout
Declared In
NSLayoutConstraint.h

The thing about App shipping schedules

I’ve come across an interesting article, Ship your app weekly | Karma that debates the notion and merits of how startups and companies schedule their shipping/release dates.
iphone-410316_640.jpg 640×426 pixels

Klass raises an interesting point, that many companies are stuck in the pre-internet days of shipping apps once or twice a year, synonimous with the days when companies would physically ship boxes of software, where logistic dictates how practical it was to distribute something according to what frequency.

It seems that the archiaic process continued with the development of iOS and Android apps, where companies and startups are focused on packing is as much feature into each release, with the fear that they need to tick all the boxes before it can reach the light of day (or the App Store). Thinking about that, we are living in the era of Agile methodology, and doesn’t agile infer that we iterate and ship regularly? Sure in most cases its about internal development management, packing sprints and releasing internally, but when many startups work lean, utilising the public through regluar releases affords you the ability to have an extensive network of people who can provide constructive feedback.

Klaas has a nice quote from Parkinson’s law:

Parkinson’s law says: “work expands so as to fill the time available for its completion”.

So, rather than deliver a massive list of changes each release, build and release frequently, and provide one or two features, so that your customers know what has changed, and it gets the right amount of attention, so that you can get sufficient feedback (both good and bad).

More importantly, in my opinion, by introducing one feature at a time you also allow your customers to learn, to evolve, without the need for excessive on-boarding. To introduce something new, you need for them to learn and familiarise themselves with it, and evolve, whilst ensuring they are not overwhelmed. This is how Facebook and other major apps managed to introduce fancy features, by introducing them slowly, so that users can explore and find it themselves without being so perplexed.

Converting Objective-C to Swift

swift-logo-hero.jpg 1,200×627 pixels

I recently went to a great SWIFT meetup at the ThoughtWorks office in San Francisco, and listened to @DavyGeek give a presentation on converting Objective-C to Swift. His github project goes through chapters of conversion scenarios, from simple Objective-C to working with memory management, delegates and so forth.

You can find his github repository at:
https://github.com/davidkobilnyk/BNRGuideSolutionsInSwift. Certainly worth looking into, as we gear up for the 1.0 launch of a new language.

Quick tip: Setting the default XCode to launch

XCode logoA quick tip for XCode (and XCode beta) users. If you have multiple XCode installations on your Mac, and you either rely sometimes on using Terminal to open an XCode Project, or by directly opening an XCode project through Finder, you can set which installation to open by default, by simply entering the following in terminal.

    $sudo xcode-select --switch /Applications/Xcode4.6/Xcode.app

Review for Sparrow iOS Game Framework

This month I decided to embark on learning abit about the Sparrow Framework for iOS, a gaming framework that takes its inspiration from Actionscript, to create impressive 2D gaming experiences for the mobile platform. Johannes Stein (@Stoney_FD) presents a complete beginner’s compass on how to approach game-development, how to utilise Sparrow within the Objective-C language, guiding you on creating a game, from start to finish. The first chapter is dedicated on setting up your environment, and for the CocoaPods enthusiast that I am, finding out that Sparrow is also a Pod. You are then guided through a skeleton template project, and getting you a bit oriented around elements and objects of the framework. The following chapter then dives deeper into creating and presenting Objects and Object Containers, along a stage. You are also introduced to macros and constants. Chapter 3 then follows on with stages and assets, as well as working with sound managers, and how all these components tie together into the scene.

The author then explains how to deal with various screens sizes, working with tweens (an animation concept I was familiar with during my days of Actionscript) and transitions, before embarking on the more advanced concepts such as sprites. Moving beyond, you then learn a bit about game logic, a slice of artificial intelligence, a great skill that is of value to you, even if you decide to work with other frameworks, such as Cocoa2D and SpriteKit. Chapter 10 and 11 I found to be specifically well written, a great guide on how to publish your game, as well as integrating with third-party services such as Game Center and Flurry Analytics.

I’ve thoroughly enjoyed **Johannes Stein ** and found the book to be well structured, with a logical flow that allowed me to follow through with the exercises quite easily. If you are interested in developing games, this book is definitely worth a read.

Compared to Cocos2d, which is nested above OpenGL 2, is a bit more complex with a bit more of a learning curve, and works across iOS and Android. Sparrow is similar to Cocos2D, and works above OpenGL, but more lightweight than Cocos2D, so you get to start distributing games quicker. If you have an Actionscript 3 bacgkround, it will be even more straightforward for you.

Concise: 3.5

Level: 4

Prior Knowledge: Objective-C, with a keen interest on learning gaming. If you have had experience working with Actionscript or various other gaming frameworks, it will help, but not necessary.

My rating: 4.5

Author: Johannes Stein (@Stoney_FD)
TitleSparrow iOS Game Framework Beginner’s Guide
Publisher: O’Reilly Media
Date: June 2014