It's a minor thing, but I'd favor a name that didn't require auditory clarification.
582 karma · joined March 25, 2008
It's a minor thing, but I'd favor a name that didn't require auditory clarification.
Person-silhouetting seems more difficult to do well than content-replacing. I wonder how this falls apart in complex scenarios? Still, an interesting idea.
I'd suggest that the information architecture flow is a little lax. You have a clear conversion goal--get users interested in your services and contact you--but to accomplish it it falls to users to first choose to click through your menu. You should have clear calls to action, starting from the landing page: "See what we do" or a couple recently finished projects, and make it easy and compelling for potential clients to contact you directly from project detail pages. I'm sure your newsletter is also a good conversion path--you could integrate into the projects section as well: "Learn more about this site in our newsletter! Click to subscribe!" I'd put your phone number in the footer too, and perhaps investigate a click-to-call implementation.
From a user-experience perspective I'd make sure every clickable element is clearly actionable (links to Facebook/Twitter/LinkedIn don't look like links) and has a hover state, consider Fitt's law (e.g. the "Web" and "Print" links on the Work panel are incredibly important, but awfully small), and validate submissions on your contact form. From an implementation perspective, the way elements scroll in on each panel is a little jumpy--maybe that's intentional, but it looks rough. From a tech perspective I'd be more impressed if you'd chosen to use @font-face instead of image-replacement, but that's a little silly.
What does "Your Piece of the Web" mean? If it's regionally-appropriate and you're appealing mostly to local clients then it's good, but otherwise, eh, multivariate test a couple options maybe?
^ Single-use apps--visualizations come to mind--deserve a pass. They do one neat thing and don't necessarily need to grow and evolve outside their niche. I'm sure one app or another will be missed.
The downside is that going to other domains/subdomains from a webapp launched that way forces a user into Safari anyways, through a somewhat jarring app-switch-transition. Since Google has an ecosystem of mobile apps they'd like you to switch between they don't want you to feel trapped in just one at a time.
Anecdotally, for starters, I've never seen a site do this for mobile.
Even sites with robust liquid layouts cannot be expected to condense to fit in 480px. At that width even ubiquitous things like a 2-column layout don't work well. Displays that small need a different approach.
Developers must be disappointed because this means the millions of non-tech users running XP (and not interested/capable in upgrading to 7) won't be automatically upgraded to a browser that can run websites built on modern technologies. Consumer-oriented HTML5-powered webapps will continue to require kludges or hacks or concessions to work for many users, and will keep requiring these until a critical mass of grandpa- or aunties-owned computer machines break and grandpas and aunties go to the Best Buy and get new ones.
Of the five: two are duplicates; those two are about updated code that's useful for iPad developers today. Two we could probably do without. One is this post.
I am constantly impressed by the curation of applications on http://www.creativeapplications.net/ . Their posts inspire me to imagine creative, engaging interfaces for my own projects.
The only thing that makes this particular article worth a look was the link to BusinessWeek's article. And the only thing that makes BusinessWeek's article worth a look--the only part that didn't amount to a guess or "info" from an "undisclosed source"--was the link to Gizmodo's article ( http://gizmodo.com/5202166/iphone-30s-video-recording-interf... ), which documents its evidence clearly and keeps its analysis firmly based on demonstratable qualifications.
You could write a Greasemonkey script that would would track what users who have installed it have up-voted. Although that is not very elegant (users need to be convinced to trust it and install it) nor effective (your dataset will be self-selection-biased to that segment of the community), it would be a kind of an interesting solution to play with.
It's an attractive enough effect, and worked especially well in the era of low-res photos and students with spare laser printer account funds.
(from the YC FAQ: "Teams thrown together for the purpose of starting a startup usually fall apart under stress. You need some kind of personal connection.")
You'll get more and more interested responses if you say something about your idea. No one's going to steal it: even if they did, the magic is in the details.
CC Attribution-Share Alike may lead to someone creating something that you can reintegrate with your original work, improving it. If you provide a dataset of 2D time-based points and someone makes a neat visualization of that, everyone is better for it.
This depends on your content. Things like photos or datasets will probably be reused and remixed more than, say, written content (which will probably be quoted and linked to regardless of license).
But "yes" to fast prototypes.
When I started learning presentation layer I went straight to HTML/CSS. Tables have always seemed ungainly and unmanageable in comparison, particularly if the project is going to be using significant DOM-modifying JavaScript, or if the layout is not set in stone.
It wouldn't be a ton of trouble to make the text bubbles expand to fit the text (one more div and splitting the background images, I suspect but won't confirm). But their goal was, I assume, to have a well-aligned, eye-catching 2x2 grid, and they chose not to support rare-ish cases where that wouldn't be what was rendered rather than cluttering their markup.
John Resig blogged about a few extant frameworks in November: http://ejohn.org/blog/iphone-javascript-apps/ . PhoneGap ( http://phonegap.com/ ) seems like the most capable (though my rating of capability is "number of times I've seen it blogged about"). For those of us with little Objective C and lots of JavaScript experience, these frameworks offer an easy vector to begin developing (basic) iPhone apps.
So, uh, I appreciate that you're focusing on making yours more useful. Long-term approval usually comes from products made with care.
While searching for a job, I physically am usually limited to a few applicable dimensions (physical location, field, experience range). If I could tailor the experience on Twhired to target those dimensions then it would make my interactions much more effective. A focus on mining or transcribing accurate location and field metadata plus an interface for drilling down based on those would be a good way to fit my needs as a user.
Also, publishing alternatively-worded stories for genderless users is a little bit of a pain for third-party developers. Customizing gender in a feed story is as trivial as typing "<fb:pronoun uid=/user id/ [+ optionally possessive/reflexive/objective=true, depending on context] />", customizing stories based on gender or lack thereof is as nontrivial as 1) registering a feed template for the new form 2) making an API request for user's reported sex (or perhaps keeping information from an earlier profile info call) 3) selecting which template to populate and publish based on the results of that poll. Nothing outrageous, but potentially annoying for developers with many newsfeed integration points who want to adhere to first-party publishing standards.
Also also, [it's been a bit since I've taken linguistics courses, but] there are going to be situations in non-English languages where you simply cannot write a sentence without encoding some gender information, wherein reforming an item to be completely genderless (and grammatically not inelegant) wouldn't be possible.
Google Treasure Hunt got me using and excited about Python again, so the other books are much appreciated.