Part of my work week is dedicated to reading and learning.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.
The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.
This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.
Wired's webmonkey has some neat notes in their UI/ UX section.
Here's a neat book by Google about web design.
Terry Martin's great blog got some great insights about design, tech and startups.
And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).
Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.
This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...
If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.
A link to our TOC consultancy company would be added to this post soon.
Thursday, February 23, 2012
Monday, January 2, 2012
The New System Dilemma
...Or, how to roll out a new system and stay alive.
When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.
This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.
So you're in a rough spot now.
You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.
In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.
So what can you do to turn the tables?
Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.
Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...
Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.
When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.
This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.
So you're in a rough spot now.
You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.
In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.
So what can you do to turn the tables?
Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.
Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...
Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.
Wednesday, December 7, 2011
Why go native?
... When you've got HTML5?
That's one question I get asked a lot in the past year.
When you've got so many cool new features in HTML5, and want to save development costs, is there any reason at all why your application should be native?
Why write for several platforms, go through the whole approval process (Difficult with Apple, less so with Android)?
Why maintain more than one environment, expert types, development environments? (And yes, I know about Flash Air Mobile, Aptana and Phonegap. And no, I don't consider them as 'native'.)
Well - There are several reasons why you would want to go native.
First reason to go native would be performance.
If you have long tables to present, large stream of information, graphics (Like dynamic maps), you might be better off native.
Second reason is better usage of your device's resources - Camera, GPS, accelerometer - These are all supported/ to be supported in html, but would not work as well as they would with native interface.
Third reason is UI conventions - When programming for a device, it's best to use its native components for UI. Simply put, your users would find it easier to set preferences and options, and learn the application in the visual language the device uses. HTML5 would never look better than a native app, especially in small mobile device screens.
Final reason would be control. You want your users to be focused in your application, rather than have four browser tabs in parallel. You might not want your users to be able to simply 'browse out' of your application (Without doing a proper cleanup...).
There's also a way to enjoy both worlds:
Applications can talk to their 'web view' programmatically: Actually, the only way to spawn a software keyboard in 'editable' divs (Like web based rich text editors do) was by wrapping your site with a small app, and have the javascript 'invoke' the keyboard via the app.
That means you can wrap a web view with a thin app, and that way get all the focus to your app.
So before you jump to HTML5, which is an obvious answer to which platform you choose, think it over a little bit - Maybe native is the way to go.
In the meantime, I'm really having fun exploring Xcode. It's not that bad, once you're used to the workflow. Of course, this isn't visual studio for windows phone (I consider VS to be the best IDE, with WP no exception), but for now - It's fine.
And, finally, here's an interesting article about a small, smart and very popular company. Instagr.am is one of the coolest companies I know. Click the link below to understand why.
What powers instagr.am
That's one question I get asked a lot in the past year.
When you've got so many cool new features in HTML5, and want to save development costs, is there any reason at all why your application should be native?
Why write for several platforms, go through the whole approval process (Difficult with Apple, less so with Android)?
Why maintain more than one environment, expert types, development environments? (And yes, I know about Flash Air Mobile, Aptana and Phonegap. And no, I don't consider them as 'native'.)
Well - There are several reasons why you would want to go native.
First reason to go native would be performance.
If you have long tables to present, large stream of information, graphics (Like dynamic maps), you might be better off native.
Second reason is better usage of your device's resources - Camera, GPS, accelerometer - These are all supported/ to be supported in html, but would not work as well as they would with native interface.
Third reason is UI conventions - When programming for a device, it's best to use its native components for UI. Simply put, your users would find it easier to set preferences and options, and learn the application in the visual language the device uses. HTML5 would never look better than a native app, especially in small mobile device screens.
Final reason would be control. You want your users to be focused in your application, rather than have four browser tabs in parallel. You might not want your users to be able to simply 'browse out' of your application (Without doing a proper cleanup...).
There's also a way to enjoy both worlds:
Applications can talk to their 'web view' programmatically: Actually, the only way to spawn a software keyboard in 'editable' divs (Like web based rich text editors do) was by wrapping your site with a small app, and have the javascript 'invoke' the keyboard via the app.
That means you can wrap a web view with a thin app, and that way get all the focus to your app.
So before you jump to HTML5, which is an obvious answer to which platform you choose, think it over a little bit - Maybe native is the way to go.
In the meantime, I'm really having fun exploring Xcode. It's not that bad, once you're used to the workflow. Of course, this isn't visual studio for windows phone (I consider VS to be the best IDE, with WP no exception), but for now - It's fine.
And, finally, here's an interesting article about a small, smart and very popular company. Instagr.am is one of the coolest companies I know. Click the link below to understand why.
What powers instagr.am
Tuesday, November 22, 2011
Go Xcode yourself
Got a new Macbook Air 13". It's a neat machine, and osx feels great, even for a windows fan like me.
Office for mac is cool, Webstorm is working, and now I'm brushing my unix skills (Installing mysql and activating the built in php and apache), and setting up my work environment.
The good ol' x40 will remain in the family, and go to my older brother.
Another thing I got a mac for was to begin learning iOS development.
Xcode is the official iOS IDE, and after a little bit of fiddling, I still haven't decided whether I really hate Objective-c, or really misunderstand the language.
The principal is supposed to be simple - Drag and drop stuff to the view, write the outlets (Bad name), write some code and then connect them (By doing lots of ctrl+clicking).
But the Objective-c language is, well, quite weird. And the whole concept is a little more complicated than windows phone IDE, FLEX, or even Android.
I will update more about what I've learned once I do some real programming (Some web request and more elaborate controls stuff) rather than just connecting a slider and button to a label...
In the meantime, I'm really, really enjoying the Air's form factor and great performance. Only minor disadvantage - 13" screen with 1440x900 display = Really really small fonts in some web sites.
Office for mac is cool, Webstorm is working, and now I'm brushing my unix skills (Installing mysql and activating the built in php and apache), and setting up my work environment.
The good ol' x40 will remain in the family, and go to my older brother.
Another thing I got a mac for was to begin learning iOS development.
Xcode is the official iOS IDE, and after a little bit of fiddling, I still haven't decided whether I really hate Objective-c, or really misunderstand the language.
The principal is supposed to be simple - Drag and drop stuff to the view, write the outlets (Bad name), write some code and then connect them (By doing lots of ctrl+clicking).
But the Objective-c language is, well, quite weird. And the whole concept is a little more complicated than windows phone IDE, FLEX, or even Android.
I will update more about what I've learned once I do some real programming (Some web request and more elaborate controls stuff) rather than just connecting a slider and button to a label...
In the meantime, I'm really, really enjoying the Air's form factor and great performance. Only minor disadvantage - 13" screen with 1440x900 display = Really really small fonts in some web sites.
Thursday, November 10, 2011
From MVC to MVP to...
MVC used to be the buzzword for client development.
Implement the model, bind it to the controller and the view, or get a framework to do that for you, and there you have it - A fast client, connected to the server, great way to deliver your application.
Or is it?
I have never seen 'clean', by the book, MVC implementation. The controller and view logic gets mixed and messed up after a couple of iterations, binding makes manipulation of data formats hard, view business logic gets implemented in controller, controller code gets implemented in the view (Sometimes because of binding), and after a while the whole code gets impossible to understand and maintain.
So what do you do?
Find a simpler paradigm, which would work!
MVP says a simple thing:
- The model stays the same. Handle data and communicate with the server/ container/ host/ whatever.
- The presenter does all the work. Business Logic, View Logic, Validation, string formatting, whatever the user does NOT do interact with.
- The view handles GUI. There's no relation between the view and the model, the presenter takes care of that.
Now let's take this a bit further, and create inheritance based MVP component:
The View extents the presenter, which extends the model, et voila!
Now you have a simpler paradigm which could actually work and expend, you can rewrite or use different views (Different devices, for example) and have your factory create the client class according to the device...
As for frameworks - There are a lot of frameworks which would do the trick, though most of them do not use the inheritance paradigm. And anyway, I like to program my own frameworks, and use 3rd party frameworks to simplify specific infrastructural tasks (Like jax-rs for REST servlet implementation, or jQuery for DOM manipulation).
So next time you hear MVC/ MVP - try to see if the inheritance model suits you. You might be surprised how simple things could get...
Wednesday, November 9, 2011
Bye bye flash.
In July, I published a comparison between FLEX and HTML5, and a quick follow up a week later, stating that Adobe is going HTML5.
Well, it seems like Adobe finally realized, that there is no way to make the Flash VM run over a mobile platform without either killing the machine's performance, or draining its battery.
The FLEX platform isn't dead though - Adobe is making its Air platform run as a VM for native applications, both in Android and iOS (And, of course, desktops). But as far as the web goes - Flash goes where Microsoft's Silverlight platform goes - Into the history books.
http://www.wired.com/gadgetlab/2011/11/adobe-kills-mobile-flash/
Well, it seems like Adobe finally realized, that there is no way to make the Flash VM run over a mobile platform without either killing the machine's performance, or draining its battery.
The FLEX platform isn't dead though - Adobe is making its Air platform run as a VM for native applications, both in Android and iOS (And, of course, desktops). But as far as the web goes - Flash goes where Microsoft's Silverlight platform goes - Into the history books.
http://www.wired.com/gadgetlab/2011/11/adobe-kills-mobile-flash/
Wednesday, November 2, 2011
Open source support pays off!
I know JetBrains for a while now.
At Time To Know, it's the tool of choice for our leading development group. (The other one is using Flash Builder).
My team uses Eclipse and Aptana for web development, but it is far from being a good HTML/ JS/ CSS development tool - Even Developer Studio is much better than Eclipse.
Luckily, JetBrains has an open source program, that gives you a one year free license of their products for your project. I've tested PHPStorm, and it's a really, really cool tool for PHP and web development. Got my license, and liked it so much, that we're getting it for my whole team now.
Only problem - you need a strong PC to run it, but on the other hand, most IDEs these days are.
I'll be testing zend studio soon as well.
So thanks JetBrains. Open source support pays off.
Another small update about simple gallery management: A fifth site is in the works, plus we're over 100 downloads so far, which is relatively nice (I don't promote that project too much...).
At Time To Know, it's the tool of choice for our leading development group. (The other one is using Flash Builder).
My team uses Eclipse and Aptana for web development, but it is far from being a good HTML/ JS/ CSS development tool - Even Developer Studio is much better than Eclipse.
Luckily, JetBrains has an open source program, that gives you a one year free license of their products for your project. I've tested PHPStorm, and it's a really, really cool tool for PHP and web development. Got my license, and liked it so much, that we're getting it for my whole team now.
Only problem - you need a strong PC to run it, but on the other hand, most IDEs these days are.
I'll be testing zend studio soon as well.
So thanks JetBrains. Open source support pays off.
Another small update about simple gallery management: A fifth site is in the works, plus we're over 100 downloads so far, which is relatively nice (I don't promote that project too much...).
Subscribe to:
Posts (Atom)