Posts
-
Have I found my new favorite SDK in Metro?
With all the major announcements from Microsoft this week, and what not, about their new Surface tablets, Windows 8/RT, and the next version of Windows Phone, it was quite natural that my curiosity got piqued, and I decided to give a second glance to Microsoft’s SDKs for the Windows Platform. All along, I had been thinking that there were just two SDKs for the newer generations of Windows (Windows 8, and WP7+). A Native SDK for the experienced developer who wants to build high performance Windows Desktop Apps and DirectX games, and a Managed Runtime SDK, based on WPF, for building Metro Apps, that would share similar functionality between Metro on the Desktop, as well as the Mobile Phone.
But Microsoft had a few surprises for me. At least when it game to Windows 8/RT Metro SDK. The Native SDK for Windows desktop was just what I had imagined it to be. Old faithful Win32/COM. DLL Hell isn’t as bad as they make it sound, if you know what you’re doing ;) But when it came to building Metro Apps, the SDK supported C#/VB development as I expected, but in addition to it, they also had a Native C++ SDK, and get this… A Javascript based SDK, that uses HTML for views.
The Native SDK was kind of expected since you already allow Native development for apps, and it only makes sense that you are able to have hooks from Metro into the native environment. But the Javascript SDK on top of a runtime based on IE 10? That is amazing and is definitely a step in the right direction! What this means is that I can design my Metro App views using Open Standards, that could be easily ported over to other platforms.
Yes, the underlying API calls are still proprietary, but at least the view layer can now be made reusable across platforms. The cool thing is, even though Windows’ Javascript API provides you with its own set of controls, like the Pivot, or the Hub / Panoramic Grid you don’t necessarily have to use those. You have the option of creating your own custom UI using basic Javascript and CSS. And there’s more to it! IE 10 has extensive CSS3 support, including 3D styles, and CSS transitions. So does Webkit on iOS and Android. Say “Hello!” to x-platform slickness! Build your UI using HTML, slap it in a UIWebView / IEHtmlView and all you have to do is hook it up to system specific backend API calls using Javascript.
You might wonder “Wait! Wasn’t this already possible before?” Well, Yes… but this is the first time there is an end-to-end HTML5 / Javascript based API for building platform-quality apps, that encourages developers to think in terms of HTML5 for building their app’s UI.
I hope Microsoft also comes up with a similar HTML5/Javascript based SDK for Windows Phone 8. The current ones based on .net/WPF, Silverlight, and XNA are good. But, having an open-standards based SDK would make it awesome!
-
Scope and Design: Design, then scope.
Continuing along in the theme of my last post, I wanted to share some thoughts on scoping projects and how to avoid some key mistakes that teams make while scoping.
For those unfamiliar with the term, scoping is the process where you estimate how long a project is going to take to complete (or estimate the scope of a project). It generally involves splitting the project into smaller chunks of work / tasks, then estimating how long each task would take to finish in “developer hours”. Sounds like a pretty simple thing to do. So, what are some of the common mistakes and pitfalls?
Well there are the obvious ones:
- Project Leads do the estimating / Individual Developers don’t participate in scoping.
- Tasks breakdowns are not granular enough.
- Time estimates for tasks are overly optimistic.
- Developers are assumed to have 100% time committed to the project.
All of the above can easily be avoided by following well-known “Agile” practices.
- Developers do the task breakdown, and the task estimates.
- Tasks cannot be larger than 2 developer days worth of time. If so, split it up into more granular tasks. This helps you in being comprehensive about the task list, and thinking through your design more thoroughly.
- Calculate time estimates using a formula that integrates the best-case, worst-case, and most-likely estimates into account. Usually, I find this weighted average formula to be spot on, when there is some thought put into the best/worst/likely estimates –
Estimate = (1xBestEstimate + 2xWorstEstimate + 3xLikely) / 6
- And then when coming up with a project timeline based on the task estimates, assume developers only get to have 6 development hours/day. It doesn’t mean that they are slacking away the other 2 hours… It’s because immediate-priority stuff always come up.
But, this post is not about those very common mistakes, and their even more common solutions. This post is about my favorite phase of any project – Design – and how it is never properly integrated into the project planning and scoping process.
No time for design:
Or more commonly, not enough time for design.
Every project should have atleast a fourth of its scope allocated for design. Personally, I would even suggest that a third of my time spent on a project should go towards designing it. The more time a team spends designing, the less time they will have to spend in the future implementing - both for the current project, and for future improvements.
Split your tasks:
Everyone knows that design is essential in software development. But, the common mistake project managers do while scoping is bundling design time with implementation tasks. If a task (Task A) requires time to come up with a design first, then split it into two: Task A-1 for Design, and Task A-2 for Implementation, with concrete deliverables for each: A simple email or wiki doc for A-1, and the checked in code for A-2. Doing so will help you get a better understanding about how complex or simple you expect the design to be.
Also, this way, you can move your design tasks to the beginning of the project and have a better estimate on when you expect the overall design for the project to be completed. Which leads us to my next point –
Design early:
Get done with most of your design tasks early in the project. Not necessarily all of it, but most of it. Enough to help you finalize product requirements, and figure out how everything is eventually going to fit back together, and work like you expect your code to. Project managers are generally good at breaking the project into smaller tasks. But what they commonly forget is that you have to eventually put these tasks back together, and designing early helps you figure out whats involved in that.
Designing early also helps product managers get a better sense of what’s feasible; what requirements are must-haves and needs to be implemented for the minimum viable product (MVP); what requirements could be changed/sacrificed; and, get a much better picture of the project’s timeline. It should be obvious by now that you your original task breakdown would have changed substantially. So, you should…
Revisit your scope:
After your initial design phase, you should revisit your original scope estimates and make modifications to it to match with the design you have so far. This is when the Scoping phase is actually complete.
Project managers generally spend an hour in a scoping meeting to come up with a scope. The good ones might spend a day for planning. That only works well for subsequent sprints (We are talking in Agile jargon here) in a project where the design has already been done, and the task breakdown is already a mature list with lots of thought put into it. For the first sprint of the project (or for non Agile projects where we don’t have sprints), Scoping should be lot more than just a meeting. It should be a process that is design-heavy.
Design Along:
Just because there was a design phase doesn’t mean you get to design every single thing at the beginning. There will definitely be design tasks that will be deferred for future sprints, and new requirements get added to a project all the time, that may require some design time. As I stated above… Split the task, design the task, then implement the task. And if you follow scrum, you know you can adjust the scope for your implementation task after you are done with the design task.
Formalize! Scope and Design: Design, then Scope.
Finally, formalize this as part of your Project Management process, and watch your projects succeed. At least when it comes to being transparent about progress, and hitting your timeline dates
-
Don't forget the Project Manager
Feature Creep (n)
'fē-chər ‘krēp\What happens when you lack real project managers, and product managers assume the role of project managers, but are still primarily focused on the product, and not the project.
My most recent project at work was to build a subscription and billing system. Well, originally it was a system to store and process credit cards. Then we realized we might as well go all out and build a system to manage our users’ subscriptions, invoice them monthly, and process automatic payments.
My original estimate to store and process credit cards - 2 weeks to build and test. (Have I mentioned I’m an overly optimistic person when it comes to estimating the scope of a project?) Then when we decided to build a subscription and billing system, it went up to 4 weeks. I felt I could get it done in 3, but decided to say 4 weeks just to be safe based on past experience, 10 years worth of it.
Well… it took 6 weeks, and needless to say, the last 3 weeks were pretty stressful, and in regular project time, probably accounted for 6 weeks in itself :) What happened??? Well, where do I start? The product definition kept changing, and seemingly simple, but complex to implement, features were added/updated every other day. I suddenly had to account for variable billing cycles in subscriptions, that were still being invoiced monthly, and the product pricing structure suddenly needed to account for discounts, and variable pricing based on duration of contract. New rules were added around when upgrades and downgrades are allowed to happen, and how overage fees get charged.
Were these changes necessary? Yes! Could we have known in advance about what needed to be built exactly? Yes! Were there things that weren’t really necessary, but nice to haves that could have been postponed? Yes! Could the Product team have communicated these requirements in a better fashion? and in a more timely manner? Yes! Could I have pushed back at product about the non-necessities, and could I have communicated the impact on the project timeline in a better manner? Yes! Did we badly need a Project manager? YES!
Project Management, when done well, is more like a form of performance art where you get to balance the product designer’s pursuit of perfection against project timeline, resource availability, and technical feasibility. Except there are no artist types here performing. Instead, a professional (a Project Manager for the still clueless) who is meticulous about tracking the details. And when I say tracking the details, I don’t mean someone who is constantly nagging you about the status of your task. That is the end result of a project manager failing to cover all the bases at the beginning stages of a project.
A good project manager ensures that you don’t have to be nagged about the status as long as you are properly doing the job you committed to. And s/he does this by tracking and accounting for all the things at the beginning of the project and by setting proper expectations. Of course, no project can be that thorough with requirements right at the beginning, and there will definitely be feature and change requests along the project’s lifetime. But with a project manager, these requests will be “managed” rather than “forced.” The project manager will act as the whip, and make sure that stuff gets done when needed, and stuff gets delegated till later when not needed right away.
I used to be a proud member of the camp that felt Project managers were just an overhead, and that good Product Managers, and Developers are enough to run a successful project. But now I see how hard it is to balance a stool when the third leg is missing. Basically, to sum up this rant… a dedicated Project manager is a must in every project. It doesn’t have to be Full Time Hire. Just someone with a whip whose only task in a project is to manage its timeline.
-
Catching up!
I realize I haven’t made blog posts as regularly as I had originally intended to. So, to catchup on lost time, here are some quick highlights.
I finished my pricing experiment with Fotoyaki, and yes, $1.99 is a better price point than $0.99… at least for an app like Fotoyaki. I might need to try the same experiment on other apps to see if the conclusion stands ground across all genres of apps. I will make another post that has more details on the numbers.
After experimenting with the price points, and being satisfied with whatever meager sales data I collected, I decided to make Fotoyaki free again as I had originally intended. Within a week of making it free, the download count went from ≈350K total to over 500K. 130K on a single day after the spanish site appgratuit.es picked up the price drop, and shot the app to #1 overall app in Spain with 97K+ downloads on a single day. The App currently has over 650K downloads, with daily count anywhere between 500 and 1200.
That’s enough Fotoyaki talk. I, along with a couple of buddies tried to start a co-creative mobile app development community a la quirky.com. To check the viability of the idea, we tried to do things in a micro scale, by setting up a wordpress blog, and using polldaddy for feedback. You can check it out at http://ripll.wordpress.com. How did the viability study go? Well, I’ll talk about that in more detail in a subsequent post as well, but the gist of it is that we are not pursuing that idea. We are however building the app, which has got some cool design elements to it… which I will also make a future blog post about. So many promises being made here… This blog is set up for failure :)
And to save the biggest update for the last… I am leaving mobclix tomorrow, and joining Bread Labs (http://bre.ad) next month. I’m SUPER EXCITED about it, and hoping something awesome gets made there!!! Going to India for 2 weeks before I start there march 1st… and super excited about that as well.
Okay, this post is almost done… but, there is…
| o | n | e | | m | o | r | e | | t | h | i | n | g |
I will leave you with Jon Ma wishing you a Happy Valentines Day! https://jonmaloves.us
-
A Vision for Interaction Design
I came across this video on the interwebs last week, and thought I would post it here. It’s Microsoft Office’s vision of the future, and how people will interact with their productivity apps. Most of it is already possible with today’s technology, albeit in a clunky hacky way. The video is more about the omni-presence of information and display technology, than it is about interfaces and user interactions. Although, it does showcase a few new interaction paradigms like touching behind the screen to interact, and flicking data between devices, or capturing it from a device (A better QRCode).
The video is heavy on Augmented Reality, and 3D displays, and pretty light on new UI paradigmns or data visualization methods. If anything, it shows how slow transitions can go from cool to annoying really quick, and get in the way of productivity. Apple learnt this (thankfully quickly) and has shortened most of there UI animations to less than 0.3 seconds. Remember the time when they were too proud of the genie effect used in minimize/restore? But, they still have some long transitions in some of their Apps like iMovie (the squeeze transition for flipping the timeline and media views… Stop being too proud of it already!). You can also see them shortening the animation timings in every subsequent version of iOS. It feels “Snappier” for a reason.
Anyway, going back to the video — I wonder if microsoft hardware has some new display technology in the works that provides the illusion of thin air display. That would be pretty nifty. And hopefully it’s not something that could accidentally scorch your retina with plasma. Here’s to hoping this vision from Microsoft becomes a reality at some level, and doesn’t go the way of the Courier.
subscribe via RSS