Zoho: Here’s a full suite of “100% free” MS Office-like online applications. Import/export common MS docs, create web-enable apps, build your own apps and widgets to extend the functionality… it’s amazing, really.
Am I ready to make the switch to complete web 2.0 100% free virtual desktops? Maybe… it’s pretty nifty, but would I trust my sensitive corporate data to their servers?
And am I out of luck during those rare times that I’m not online? Nope, they have a downloadable app version.
The recent work/life balance event I put together has got me thinking (again) about the way I spend my work time and the nature of what is “work”. Stephen Beck sent along this interesting link: a story on the Stats Canada study on how much Canadians are working. It makes me wonder who these slackers in British Columbia are — working an average of 1700 hours a year? That’s about 34 hours a week, minus two weeks vacation. Up to this point in the year, I’ve put in over 2100 hours, and I’m on my way to wrapping up with over 2200.It’s very interesting looking back. In 2001, I felt like I worked my butt off, really didn’t like what I was doing as much (more managing than designing), and felt like I was already approaching burnout. But when I now look at my hours for that year, it was 2200 — less than I’ll probably end up hitting this year. But this year, even with two kids and arguably more stuff happening on the side, I feel like I’m more balanced, profitable, and more satisfied with work than ever.
It certainly seems true that the nature of your work and the rewards of your work situation impacts your efficiency and the perception of how much your “work” drains away from “life”. Last year (2005), I think, was the perfect balance for me — 1900 profitable hours worked, with about 6 weeks of time off (including parental leave): that equals happiness!
Things are looking good in the new stoo-day-oh. We can finally breathe and move around without bashing our hips, and I think that’ll translate into more efficient designers, smokin’ websites and lots and lots of money.
Shopping for the office is fun and not so fun. I just love running out and spending the boss’s money on stuff that I think will look cool or will make the office swankier. Then I realize that I am the boss. Nuts. Then I go and return useless crap that the boss thinks is too expensive. What a dick.
I spent much of last week at Home Depot. And IKEA. And shopping for furniture at stores with other gay people in the middle of the day. I’m not gay, but somehow I seemed to bump into the same gay couple at every furniture store in South Granville. Trying to make them feel like I wasn’t stalking them, I’d joke around and say stupid things that, upon reflection, probably made me sound like an insane and lonely loser. Which I am also not.
I ended up buying a couch and chair set (I was initially opposed to the pedestrian idea of a “set”, how droll) from Moe’s. Yes — a furniture place called Moe’s. But it’s cool — the dude’s name is really “Moe”, so whatever.
At the start of the move we were all stoked, which is probably why things got done faster. We were out of the old place and into the new literally within a few hours. But by the end of week number one of “moving mode” — between client work intrusions (what? we still have to work??), shopping numbness, and brittle plaster walls that don’t hold up pictures very well – much momentum was lost. In the end, it took one day of me taking a hard-core “I’m not leaving until I’m frickin’ done” attitude to rock out clear the decks. I rocked out with the organization, man. In anticipation of the new couch set, actually. We had to make room.
Now, there’s still a pile of cardboard rubble in the corner of one room, and I have stacks of docs and papers a mile high to review, but it finally feels like it’s coming together.
We have red lockers.
We have comfortable yet stylish seating.
We have nice track lighting.
We have a coffee table with design-y mags and type books I’ve never had time to open.
There’s still a lot on the 2-frickin-do list (plants, picture frames to mount, rubble removal, sinks to put in, and on), but it’s closer than ever. I’m looking forward to the mod7 “open house” – when we invite all our clients and friends to casually drop by and help us drain our fridge of all the beer that BURNKIT sent us.
Cause it’s probably the one time I’ll get the chance to actually use our new couch set.
In this article, the author takes a stab at creating a naming convention for universal web page elements. Ambitious, if not a bit simplistic.
In general, I’m in favour of this sort of thing on a corporate level.
On a related note, I appreciate this guy’s motivation for introducing such conventions:
“…as a businessman I would like to establish conventions which make my development time more efficient and therefore more profitable.”
This is a big challenge for companies like ours, who pride themselves on unique solutions to unique problems. There isn’t a lot of space for process and workflow flexiblity when every project is so vastly different. (”vastly” is a bit of an over-statement, sure — it’s not like we’re making websites in one project and then stuffed bears on the next…)
Regardless, looking at this guy’s suggestions, I already see that it doesn’t apply cleanly to one of the music-based websites we’re working on. His conventions are:
- #container
- Page container (usually a
)
- #branding
- Used for a header or banner to brand the site.
- #branding-logo
- Used for a site logo
- #branding-tagline
- Used for a strapline or tagline to define the site’s purpose
- #nav or #navigation
- Used to contain a navigation device
- #nav-main
- Main or primary navigation
- #nav-section
- Navigation to pages within the current site section
- #nav-external
- Navigation to pages outside the site
- #nav-supplementary or #nav-supp
- A supplementary list of links, perhaps in a footer. This can replace the common, but presentational #footer
- #nav-(whatever)
- A list of links named at a designer’s descretion
- #search
- Related to search interface and search results
- #search-input
- A search form
- #search-output
- Search results which could include a
or other markup including definition lists
- #content
- Used for content rather than for another purpose such as navigation
- #content-main
- The main content area
- #content-news
- News related content
- #content-(whatever)
- Could include any form of content, including #content-related, #content-quote etc.
- #siteinfo
- Used for various site related information
- #siteinfo-legal
- Copyright information etc.
- #siteinfo-credits
- Designer or other credits
E-commerce related
- #content-products
- An overall area containing products
- .products
- Referring to individual products
- .products-prices
- Prices, discounts, special offers etc.
- .products-description
- A summary or longer description of a product
- .products-review
- A customer review
- .products-(whatever)
- Could include any form of product related content
This is great for corporate brochure sites or blogs, but it gets pretty restrictive (and thus useless) for some of the kinds of things we do.
That said, I still can’t underscore enough the importance of establishing consistent conventions on the project level. This is critical and sometimes gets brushed aside in the rush to “get it done”. Which brings me back to my original lament — I wish we could get rolling on the production of projects sooner by using a standard framework of conventions (and not redesigning the wheel on every go)!
Gamasutra - Feature - “Paper Burns: Game Design With Agile Methodologies”
This article talks about the ”Agile” development method, as applied to game development. I can see this as quite applicable to interactive design. We kind of work this way already (though on a much, much smaller scale): we rapid prototype, get the client involved early and often, work flexibly, and test throughout.
The one thing this article alludes to but doesn’t answer to my satisifaction is how costs are controlled. Yes, the traditional ”Waterfall” method (akin to an assembly line) may be inefficient and lead to degraded products, but how does one plan and budget for the potentially limitless iterations of Agile? This may not be an issue in game design, but for projects with strictly fixed budgets and deadlines, I can’t see how this is “controlled” effectively.
Perhaps, I’m just not getting the point that this methodology may apply more for large teams developing really large, really complex projects.
Still, it’s nice to see our approach validated, even if not directly.