Another canvas-based toy, in honor of all the snow we’ve been having around here lately: The Snowflakerator.
Lets you draw in 6-way radial symmetry. I got the idea from those folded paper snowflakes that everyone used to make as a kid.
I’m liking canvas, it’s easy to do some fun stuff with. And I really like it not being the black box on the page that Flash tends to be.
More of these to come, probably.
A couple of weeks ago, my former colleague Mike @ Meja Design released this cool visualization of the digits of PI mapped to colored dots:
This got me thinking about other transformations you could do over the same set of numbers. At the same time, I’ve been wanting to start playing with canvas, for possible future infographicky goodness. So I thought, what better way to get my feet wet with canvas than to visualize PI as a line chart! And just for fun, I put it on a circle too, since, y’know, PI. (I was going to make the lines nice and curvy, but it’s the weekend and bezier curve math was not being my brain’s friend, so straight lines for now.)
So, without further ado: the digits of PI visualized as a line chart, using canvas. (Also: I threw in excanvas, but didn’t actually bother to test it in IE, so if it doesn’t work, um… try a real browser, I guess? Cheers.)
Is it even possible to successfully apply the principles of open-source software to design? Or does really great design require a certain level of Steve Jobs-like tyranny, a sense that one vision is masterminding everything, or at least a single point of responsibility?
(By “design”, I’m referring to visual/experience/industrial/graphic/architectural/service/fashion design — all of the fields that deal primarily with creating some sort of effect or experience for a human being. I am not referring to things like the design of circuits or of hardware. Those fields are different.)
The relevant difference that I see is that really great software is usually quite modular. Software engineering principles like encapsulation and loose coupling mean that lots of people can work on something, each one taking a part, and still come out with something that integrates quite well and does what it is meant to do. This is probably what makes open-source projects work as well as they do.
On the other hand, really great design is incredibly integrated. If you look at a great experience, one of the striking points is the way in which every single aspect, from building architecture to package design to software interfaces, makes an integrated and coherent contribution to the experience. It has a personality — one personality, not a schizophrenic array of different voices all talking at once.
I wonder, given its coherent and integrated nature, whether great design is fundamentally incompatible with the open-source model. After all, “designed by committee” is a common insult, but there isn’t really an equivalent phrase relating to programming.
How much specialization is too much specialization? And how much of a generalist can a person really be, and still be effective? This question comes up for me a lot, because I tend to be a generalist in an organization that encourages specialization and separation of roles.
On the one hand, specializing in one technology / programming language / skill allows you to gain a depth of knowledge and experience that you can’t really fake. Some have argued that it takes about 10,000 hours of practice to become an expert at something; if you practice a skill for 30 solid hours a week, that equates to about 7 years. After 7 years of working with a skill, I have to imagine that you know pretty much everything there is to know about it, and your intuition has got to be pretty solid on any question or problem that comes on.
On the other hand… technology and practices change so rapidly, and you have to flow with the river or you’ll be swept away. If being a generalist means that you have the ability to rapidly teach yourself new skills, and the willingness to learn as you go without hand-holding, then arguably generalists are better prepared to deal with the changes that inevitably happen. Also, like I discussed in my post on designing and developing, being able to cross between fields allows you to make connections that might not otherwise be made.
Perhaps it could be seen as a risk/reward tradeoff.
Specializing is like investing in stocks, with more risk and a potentially higher reward. Specialists have an easier time getting hired — their resumes fit the traditional ‘check the box’ model — and they quite possibly get paid more for their expertise. On the other hand, they run a high risk of their skills becoming obsolete, or at least less valuable over time.
Being a generalist is like investing in bonds, with a slower payoff but much less risk. Generalists have a harder time making people understand what they do, and may have a harder time demonstrating their worth to prospective employers. But they will always be able to adapt when the technology or the environment changes, and figure out how to make themselves useful in some way.
And perhaps there’s a happy medium of sorts, where it’s possible to keep learning and using one central skill, while always having a rotating cast of new things at the periphery. It may take longer to become an expert this way, but like a balanced portfolio, it seems to offer the best mix of reduced risk and potential reward.
For myself, the nature of my current job is very general. I have to be able to pick up whatever tool is best to convey the idea at hand, whether that be css/javascript or Flex or Flash or PHP or JSP, or whatever the next thing will be. (And I have to be able to adopt the design mindset as well, which has its own set of skills that aren’t as easily defined.)
I would say that css/javascript is really my core expertise, if anything is. I’ve been doing a lot with Flex the past few months, but it’s really all in the data visualization space; I don’t know anything about Flex app development outside of that. I dip into Flash when necessary, and usually get confused because it’s different from Flex. I know enough PHP to get things done, but I don’t really have a depth of experience, and I still have to refer to the docs a lot.
So this line of thinking implies that, no matter how much my job comes to involve other things, I should make sure that I am still keeping up with my css/javascript skills and following new developments with those technologies. Because at some point in my life, I’m going to have to label myself again, so I need to have at least one language where I can call myself an “x developer” and feel entitled to the phrase.
I’ve put together a simple bookmarklet to allow you to add Photoshop and Illustrator-style guides to any webpage. This is something that I’ve wanted for awhile, after finding myself feeling ridiculous while holding a sheet of paper up to the screen to check whether things are lined up.
Just drag this link to your bookmarks bar, or right-click on it, or save it however you save a bookmark typically:
Guides Bookmarklet
When you click on the link, grey bars will appear across the top and left side of the page. From these bars, you may drag out as many guides as you need onto the page. Guides can be repositioned once they are on the page as well; just hover until you see the little arrow cursor. Finally, to remove a guide, just drag it off the side of the page. (That last part may not work in IE.)
This is version 0.1, meaning that I worked on it for about 3 hours overall. So tell me: as a web designer or developer, what would make this more wonderful to you? What other features would you totally use?
Also, please let me know about any bugs!
(Notes from Ryan Stewart’s keynote talk at Philly Flash Camp.)
Contextual Applications:
Adobe’s Product Line:
And my example files:
demo.fla
demo.html
[Edit: I forgot to mention that my html file is using the swfobject.js library to embed the Flash object. It may be acquired here.]
I. An interface is a window between two complex systems.
Most of the time, one of those systems is a person.
The interface marks a boundary. It is the place where the human meets the machine.
II. Most software is incredibly complex. Often, it is so complex that not even one developer who built the system can keep the whole of it in her head at the same time.
Information passes from place to place, is modified, recombines, evolves and mutates in a thousand different ways. An interesting program is a highly choreographed dance of a thousand different pieces of data.
To make it even harder, this happens on many levels at once, from the base electrical impulse guided by physical law, all the way up to conceptual objects that contain, modify, and recreate one another.
The fact is, there’s a lot going on.
Meanwhile, on the other side of that boundary, a person is… a person.
Talk about complex.
III. An interface is a window. It is also an adapter.
The user wants to get something done. He has in his mind a model of what he is trying to do.
This model comes from his life experiences, psychology, learned behaviors, things he’s observed in other people, and probably 20 million other subtle factors.
The system also has a model. This model is built up over time, a slow accretion of 20 million small choices made in every line of code, in every aspect of the system design, during every step of the development process.
The odds that this model matches the user’s model are very, very small.
It’s the job of the interface to translate between the user’s model and the system’s model.
It’s the job of the interface to manage and reduce complexity.
(To compliment an interface, call it deceptively simple.)
It’s the job of the interface to bridge, not just 2 worlds, but 2 million — the world within the system, and the personal worlds of 1,999,999 different users.
That’s why making interfaces is hard. That’s also why it is worthwhile and necessary.
Because you could make life frustrating and difficult, but instead you get to make it pleasant and simple. Because you get to bring a small bit of order to a whole lot of chaos. And because you get to make things, in some small way, better or easier or more fun than they were before.
This past Monday I got to attend the Dev Days conference in Washington, DC. While it wasn’t the most useful conference I’ve ever attended — that honor would have to go to The Ajax Experience in 2008 — I still learned a couple of new things. Following are some items that I found interesting enough to share.
“Asking users to confirm something that they are not qualified to confirm is useless.” – Joel Spolsky
This quote was referring to security-related alerts and confirmation messages. Joel argued that 99.9% of users have no real understanding of the consequences either way, so asking them to confirm or approve something is meaningless. He asserts that many times, this pattern is a result of the developer or company trying to avoid responsibility.
The implication I take away from this is that the system should pick the “right” thing and just do it, while giving advanced users an option to override and do something else. I thought that this was a very thought-provoking point.
OPower looks like a really awesome company, and it is very cool what they are doing with psychology and design to encourage folks to conserve energy.
Bruce Eckel, who apparently has been programming forever and written books on every language in existence, gave a really interesting history of programming languages (with digressions into Burning Man, the TED Talks, and how 80% of people hate their jobs).
I was already interested in Python, but thanks to his talk I am now convinced that I actually want to learn it. Perhaps this will be a project for next year. (And after that, a purely functional language, like Haskell, because it is completely different from everything I know.)
Joel is a master of shameless self-promotion. I’m not trying to be snarky when I say that I think it’s what he does best. Throughout the conference he was continually promoting himself, his company, and his product.
Being really good at self-promotion can go a long way toward success, I think. I could learn from this, because I’m not necessarily so good at it myself.
Was Dev Days worth it?
I would go back if they had one in Philly. But overall, I don’t think it was worth the cost of the hotel and the drive time to DC. I would say about 25% of the sessions were useful or interesting to me.
I rate it worth attending only if it’s convenient and nearby.
Over lunch today, I was watching this excellent overview of HTML5 by Brad Neuberg. One of the topics he goes over, along with Canvas, SVG, and native video, is the new app cache + client-side SQL storage, which together make it easy to create full-featured web apps that work just as well without an Internet connection. (It’s like Google Gears, but native.)
My thought was, could this do for web apps what the cell phone has done for telephony in developing countries?
Let me explain what I mean. In developing countries, such as most of Africa and parts of Asia and South America, cell phones have quickly overtaken land-lines as a means of voice communication. According to this source, Africa has more than twice as many cell phones as land lines, for example. The reason, of course, is that less infrastructure is required, so the barrier to entry is much, much lower. You still need a cell tower, but you don’t need to string phone lines everywhere. (Jan Chipchase, who has the really cool job of studying this sort of thing for Nokia, has a lot of interesting things to say on the topic of cell phones in developing countries.)
The same places in developing countries are likely to have Internet connections that are sporadic at best, lower-bandwidth, and probably with a lot more people sharing one connection. (According to this source, 13% of people in developing countries overall had Internet access in 2007.) Could these new features from HTML5 promote the development of relevant web apps that make life easier for someone who can connect to the Internet only once a day? Once a week? Even less often than that?
I have trouble imagining what such an app might be, because I don’t live in that context. Broadly, one category might be applications that pull down a large amount of information and store it for the person to use later, when they don’t have Internet access. Another might be allowing the person to create and store a lot of blog posts or other ‘pushes’ of information, and then upload them all later when given access.
While greater access to information and communications technologies is not a panacea by any means, it sure can do some interesting things.
Could offline web apps be the next tech phenomenon in developing countries? Or are even the smallest netbooks still too big, too expensive, too power-hungry, or too fragile to reach the level of usefulness that cell phones have achieved?
You are currently browsing the archives for the development category.
