It's time for some more links to inspirational stuff...
This 2009 article at wired is one of my favorites. It talks about how 'good enough' easily beats 'great' in so many aspects. Whenever approaching a big design or architectural task, I tend to go back to this article a little bit. People tend to over design stuff, and try to come out with a Lamborghini (That costs like one to develop, sell and maintain), when all their customers want is a Mazda...
If you're always looking for 'the next thing' in dev technology and new stacks, you have to visit the changelog regularly. Lots of emerging technologies, useful libraries and code - All the goodies us geeks need.
For all you non-coders out there, here's a great article on starting a tech company without coding knowledge, and, this great article by @martingryner shows the other side of entrepreneurs recruiting a tech co-founder.
The new iPad paves the way for laptops, PCs and tablets with astronomical resolutions. As resolution gets higher, sites with dynamic adaptation to screen resolution need to scale differently. A simple reflow is not enough - Reflow your site, and your font size will be too small to read. Scale your site, and graphics quality degrades. This article gives some pointers about redesigning your website for retina displays.
And, finally, here's an article comparing between the two leading cross platform mobile development SDKs - Phonegap vs. Titanium. If you're considering cross platform app development, you should read this one.
Monday, May 14, 2012
Thursday, May 3, 2012
Hacking your product...
During every company's life cycle, there comes a time where you have to think about strategy.
Where do you want to see your company a year from now? Five years?
The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.
This is how Amazon kicked off their AWS product...
Where do you want to see your company a year from now? Five years?
The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.
This is how Amazon kicked off their AWS product...
Sunday, April 8, 2012
Simple Gallery - The next phase
Been thinking a lot about my Simple Gallery Management Project.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.
I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).
This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.
Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.
I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.
In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))
I'll update soon, once the new version begins to show signs of life.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.
I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).
This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.
Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.
I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.
In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))
I'll update soon, once the new version begins to show signs of life.
Monday, March 5, 2012
Big data, small code
Building a big data driven web application used to be a big thing. Relational databases, links tables, complicated queries and stored procedures...
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.
With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.
Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.
Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.
My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.
Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.
With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.
Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.
Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.
My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.
Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.
Thursday, February 23, 2012
Reading time!
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.
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.
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
Subscribe to:
Posts (Atom)