So you have a rake. Part of a rake is a long stick. And so you think to yourself, hey, back scratchers have long sticks too! Let's put a mini "rake" on the other end of the actual rake and boffo!
The Snowball Begins
52 Clix hosts monthly photo walks in the San Francisco bay area. We're walking Land's End in San Francisco on Nov. 15th if you're interested. Anyway, we wanted to get the word out about the walk, so our first lame attempt was just to manually do everything. It was tedious. Moreso than it needed to be, particularly when this was going to be a regularly recurring event. The engineer in us wanted automation. And it wanted it now.
Over the course of a day, the input screens to put the photo walk on the site and the design of the consumer-facing page were completed. The image slicing and HTML/CSS the following. And then...
The Snowball Starts Taking Out Skiiers
When you build tools that only one person is using, you get this sense that the tool isn't fulfilling its full potential. And then suddenly it's like looking at the stick on a rake and saying, "hey, this could be a back scratcher too!" On one hand, you're right. The pocket knife is a great example of extending utility out of one tool. On the other hand, if the knife is a $200 blade made for dicing vegetables, adding a can opener, spoon and fork to it doesn't make much sense. Keeping focus on purpose is important.
So after spending time looking at the photo walk publishing tool we were building, the thought occurred to us to make the tool available to everyone. We could build an entire Events section! Members could post their own photo walks, gallery events in their area and more! How exciting! And we were off to the races on adding features like saving events, filtering events your friends were attending and nearly adding the latitude and longitude data mentioned in a previous blog post.
The Snowball Stops Rolling and Starts Melting in the Sun
The Events section was launched a little over a month ago. It instantly looked barren. It instantly became this needy creature on the site. We started hunting the Web for other photo events to add to our events section. We only did this for the bay area, because that's where we're familiar. It was hard. It was annoying. And worst of all, it was taking up space on our Web site with only tangential appeal to our core product. The problem was only compounded with our members coming from all over the US - what did Texans care about a book signing in San Jose, California? We didn't offer any regional filtering in the v1 release of Events.
In the end, the amount of time devoted to this just started to seem more and more silly. People aren't coming to our site to look for this weekend's hottest photo event. It was a focus away from the core product and in the next week, the Events section will be a distant memory. Never be afraid to take a scalpel to your product.
Several years and fewer gray hairs ago, I developed an application just like Citysearch for a client. It was focused on restaurants which catered to the wine crowd, with byob service.
The client requested the ability to search restaurants through a radius. "I want all restaurants within 15 miles of Hoboken, New Jersey." At 20 years of age, I probably shouldn't have told him "no problem" before doing my homework. Fortunately, naivete is counterbalanced with determination at 20. You work dumber and harder as opposed to working smarter when you get older. But I digress...
Free as in Beer
Did you know that the United States Census Bureau gives away its city, state, zip code, latitude and longitude data for free? No foolin'. Just visit the U.S. Gazetteer Web site and download the flat files with the data. This data coupled with a math equation to determine the distance between latitudinal and longitudinal points is all you need to add regionality to your application. For PHP developers, there's a open source project called phpZipLocator to speed up the process.
How We're Using it
At 52 Clix, we're adding an Events calendar section and we'd like for our users to be able to choose to display only events relevant to their region. We prompt the user once for their home zip code. With the census data called "Zips," we look up and store the latitude and longitude.
When an event is created, the poster enters the city and state. We use the census data called "Places" to look up and store the latitude and longitude. We do not ask for the zip code because it's often the case that someone doesn't know the zip for a particular place. Some cities have different zip codes every 10 blocks!
Once the lat/lon is known for each of the points, we simply query our database with the distance math equation. We're using the query found in the GPL'd package Zipdy written by V. Alex Brennen.
After a painful struggle with an odd visual bug, I can fully declare victory and share my learning with The Internets.
To the Point
I was going to give a succinct problem and solution here, but I honestly have no idea what the reason is behind what I'm seeing. What am I seeing? Firefox rendering my markup differently once the Gecko rendering engine gets a hold of it, specifically puking when a DIV was in an A and a P inside a STRONG. With that said, there's a lot more markup and CSS involved than simply those 2 nested tag examples. This may only be helpful for you if you noticed Firefox is rendering your markup differently than it's written (thank you, Firebug!).
Background
Above is what the visual bug looked like. What was particularly
annoying about this bug was its random frequency. When you reloaded the
page, sometimes all of the member images would sit in the left corner
like they were supposed to.
I traced the problem down to the following rendering difference (using HTML 4.01 Strict Doctype):
Correct HTML
Rendered HTML:<span class="clear">
<a href="score.php?id=X&photo=X">
<img class="winner" src="img/global/scored.gif"/>
<img class="photo" src="img/submissions/0/m/xxxxx.jpg"/>
<img class="spaceball" src="img/submissions/0/m/xxxxx.jpg"/>
<div class="member">
<img class="avatar" src="img/users/0/s/xxxxx.jpg"/>
</div>
</a>
</span>
<span class="clear">
<a href="score.php?id=X&photo=X">
<img class="winner" src="img/global/scored.gif"/>
<img class="photo" src="img/submissions/0/m/xxxxx.jpg"/>
<img class="spaceball" src="img/submissions/0/m/xxxxx.jpg"/>
</a>
<div class="member">
<a href="score.php?id=X&photo=X">
<img class="avatar" src="img/users/0/s/xxxxx.jpg"/>
</a>
</div>
<a href="score.php?id=X&photo=X"> </a>
</span>
The Fail Train is highlighted in red. Firefox hits the DIV tag inside of the A tag and decides that the A tag needs to be closed. I don't know why. There's no validation rule that says a DIV cannot go inside an A tag. From that point on, it's doing all kinds of wacky stuff - inserting the A tag inside the DIV and an empty A tag following it?
I've isolated just this bit of HTML to a page and tried to reproduce the visual bug, but it seemed to work every time. When the rest of the HTML was re-introduced, the bug reappeared. No CSS was being applied to the markup.
Help me Obi-Wan
As engineers often do, I took an educated guess at a fix without fully understanding why I was getting the incorrect rendered markup. Since it was the DIV it was hitting that caused the A tag to prematurely close, what if it weren't a block-level element? After all, that was a difference between the IMG tags it was still encapsulating and the DIV it was not. So I swapped the DIV out for an EM. It worked. It worked every time I reloaded the page.
A related problem was a P tag sitting inside of a STRONG tag. Again, I don't believe there's any validation rule which states this is invalid, but sure enough Firefox would sporadically end the STRONG tag when it hit a P inside of it.
Correct HTML:
<div class="number clear">
<a href="score.php?id=X&photo=X">0 comments</a>
<strong class="no">
<p class="z">Score:</p>
<p>hidden</p>
</strong>
<p>5 scored</p>
</div>
Rendered HTML:
<div class="number clear">
<a href="score.php?id=X&photo=X">0 comments</a>
<strong class="no"> </strong>
<p class="z">
<strong class="no">Score:</strong>
</p>
<strong class="no"> </strong>
<p>
<strong class="no">hidden</strong>
</p>
<strong class="no"> </strong>
<p>5 scored</p>
</div>
Like the DIV in the A problem, I simply made the P tag an inline-level tag and Firefox was happy. This seems like a Gecko rendering bug, but I'm not certain. Hope this helps some people out.
If you find out the reason for this, please let me know in the comments. Thanks!
posted by Ryan Gillespie
There are a lot of factors which go in to making a successful social Web application. Keeping spammers at bay, ensuring a snappy response time for users, slaying the Fail Whale and so on.
However, one feature to a site that must exist as you become successful is the ability to make your large site feel small again.
What's your problem?
As a member of Yelp since 2005, I've seen first-hand the turnover of active membership - viewed here as people who participate on message boards, create and comment on events and consistently engage in communication features - as a site grows. I look at the active users on Yelp now as the 3rd generation. The first 2 broke off the site and some of them founded their own little communities, essentially retaining the culture they had developed for themselves on the site.
In each generational shift, you saw the same thing. As those outside of their culture joined the site, there is an initial snarkiness amongst the majority actives. Essentially, they are telling the noobs they better get in line with their culture, or they're going to give them a hard time at every turn. Eventually, enough noobs overwhelm the current size of the generation and the generation feels disenfranchised. They reminisce about how cool the Web site "used to be, before all these new people joined."
This concept will likely seem obvious to most people. In high school, sophomores think freshman are out of touch. The Baby Boomers think the X Generation has bad taste. Punk feels betrayed by post-punk, as seen the documentary Kill Your Idols.
My friend Chris and I were chatting the other night and he brought up something he had read in The Tipping Point, a book I've owned for 2 years but have read to actually read. He told me about The Rule of 150, which is the idea that at most 150 people can work together in harmony and be productive. While the book highlighted this in a professional, co-worker scenario, it's applicable to the online world as well. If I had to make an estimated guess at how large the active community was on Yelp, it was probably quite near 150 each time there was a fracture.
What's the solution?
How you make a site feel small again is naturally unique to each one. Flickr has Groups, for instance. The fundamental fact is you need the ability for your users to organize themselves. It's not enough to simply create your own organization and expect users to slot themselves into your structure. Because unless you have your finger on the pulse of each grouping you've created, you'll never know when or how to fracture them. Leverage the feelings of your users and give them the tools to self-organize.
Lastly, you shouldn't half-ass the tools for organizing. It's easy enough to create something you call "groups" that users create and join. However, if there's very little to do beyond join the group and state that you're a part of it, you've failed in your design. Each group needs to feel like they have all of the features of your site, but limited to a self-organized subset of members. Stop defection - go small once you've gone big.
posted by Ryan Gillespie
Firefox 3 was released about a month ago as of this post. It's definitely zippier, which any user can love. And it's now Acid2-compliant, which CSS nerds love. The people who don't love it? Those of us who have to fix our code to play nice with its new rendering engine. Yeah, we can hear the CSS evangelists screaming "Well if you wrote it 'correctly' the first time..." (quotes on the fictional statement ours)
Below are got'chas we faced when Firefox 3 users started coming to our site. Sort of a CSS Firefox 3 vs Firefox 2 cheat sheet.
Floats
Widths and wrapping floats
The main problem here is that the width of the parent element (the red box in the image below and the 2nd LI in the code below) is unspecified, but its children elements are floated and do have specified widths. The parent's parent (the UL in the code below) has a width applied that forces the DIV element to wrap. This works as it should across all browsers. Where Firefox 3 gets you though is the actual width of parent element, despite the fact that the element wrapped, is equal to the total width of all its children widths. Before, in Firefox 2, the parent width would be equal to the right edge where the child elements stopped (the red box in the Before in the image below). Now, however, you get the wider parent width (the red box in the After in the image below).
Example Code:
<ul style="width: 300px;">
<li style="float: left; width: 100px;"><img .../></li>
<li style="float: left;">
<p style="width: 200px;">Today at 2:00p</p>
<div style="width: 100px;">John Doe</div>
</li>
</ul>
Solution:
For our purposes, we just specified a width for the parent element. If you were to need a parent element that required a mutable width, we're not sure how that would be handled.
Leading edge of the unfloated
Okay, the first was was a pretty specific and hairy one. This one's bound to be more common.
It's perfectly valid to have a non-float next to a float. The non-floated will sort of appear to float when it's really just wrapping around the float. The got'cha here is bounding box for the non-float is actually the same edge as the float now (the red box in the After in the image below) whereas before the bounding box's edge was equivalent to the opposite edge of the float (the red box in the Before in the image below). This means paddings and margins are not applied the way you would expect them anymore; also, if you are changing the background color of the non-float on :hover, it will put a gnarly colored box over your floated element.
Example Code:
<div style="float: left; width: 100px; height: 100px;">.</div>
<div style="padding: 0px 4px;">Text</div>
Solution:
For our purposes, we specified the non-float to be a float to allow our element to "push" off the other float and to prevent our :hover from putting a colored block over our other floated element.
Negative z-index
It's recognized now.
Our bitterness over overlapping struggles with Son of Suckerfish and our cavalcade of relative and absolute positioned elements aside, you can specifiy a negative z-index in Firefox now and it may have made all of your anchor tags unclickable. In IE, they are still clickable.
Example Code:
<a href="#hello" style="position: relative; z-index: -10">World</a>
Solution:
Set your HTML tag to be a negative z-index lower than the z-index you're using on your A tags. In the example above, a negative z-index of -20 applied to the HTML tag will make the link clickable.
Inline-block element
It's recognized now... and it's breaking your clearfix
Once we get over our kerfuffle with updating the code, we're sure we're going to be happy to finally have inline-block in Firefox at our disposal.
The problem, and the solution, here is simple. Clearfix (thanks, Position is Everything!) makes the tag it's applied to inline. It's pretty common that you had it previously applied to a block element that isn't explicitly defined as a block element in your CSS (like a DIV).
Example Code:
<div class="clearfix">I'm not on top until I'm declared a block</div>
<span>I'm on bottom</span>
Solution:
Obviously, specify your elements as blocks, but also push your clearfix CSS as high up in the file as you can, such that it doesn't override any of your block specifiers.
Client-side image resizing
52 Clix expects to have 2 types of users: photo casualists (this is not a word) and photo enthusiasts. We love both groups and so we want to cater to both. This blog post discusses meeting the needs of the casualists (still not a word), who we expect to have little interest in resizing and touching up their photos before submitting to a Clixie. The casualist wants to drag the 8 megabyte+ image right from their memory card to our Web site.
52 Clix doesn't have nearly the bandwith or storage capacity as the big guys (jealous glare at Flickr) nor the money to afford such luxories (jealous glare at Warren Buffett), so in the interest of cost-savings, and to some degree the user experience, we implement client-side image processing via Thin File's Java applet Thin Image Upload. We hope bypassing high-res JPEG file uploads is one of those un-noticed, but appreciated features.
For the most part, Thin Image Upload works like a champ. Users can drag the image onto the target region in the applet or browse their hard drive via Java's horrendously ugly file browsing UI. The applet resizes the image on the user's machine and pushes it to your server. Not bad.
Where things start to fall apart for Thin Image Upload is in its resizing algorithm. You can specify a JPEG compression, like any graphics library; however, the sharpening is a bit overzealous, something akin to Photoshop's "Nearest Neighbor." We're talking Playstation 1 jaggies, folks. The ill-effects are worst in images that feature fine lines, such as bridge cables or your uncle's spiffy pin striped zoot suit. To be fair, Thin File is likely just using the built-in Java graphics algorithm.
But this post isn't about the product as much as it is about answering the question, "how do we satisfy our users' expectations with a known constraint?" With the pin striped zoot suit craze in full-effect, we can't ignore the problem. The solution we've come up with is a mixed bag of image resampling. We allow Thin File to handle the first resizing pass, which is an image dimension somewhat bigger than our final. We still save on bandwith and meet the user expectation of a fast site. Once the image has been transferred though, it's time for the GD library in PHP to take over and make the image a bit prettier. The GD library's resizing algorithm is similar to Photoshop's default "Bicubic," resulting in a smoother-looking image. Interestingly, because the first pass is so sharp, by applying the final, smoother resizing on it results in a nice level of sharpness. When shrinking an image you often want to increase the sharpness anyway to push out some of the details lost. Serendipity, baby! Does Vitale own a copyright on that phrase? We hope not.
There are some small tradeoffs with this approach. First, we're pushing more bits upstream across the Intertubes, from an average of 70k before to about 370k now. On 56k modems, that's about 70 seconds. Not optimal, but reasonable. Second, PHP is now being tasked to do some additional work. That said, the improvement in photo quality far outweighs those negligible negatives. View the difference in the image comparison below - click to see the orginal image before Vox blog resized it.
So what about our enthusiasts? You know, the people who agonize over the levels in their photo and a 2.1 versus 2.2 radius sharpening. For those folks, they simply upload their photos at the exact size we use on the site and so long as the resulting file is under 70k, no automated process will touch it. The enthusiast gets exacting precision and the casualist gets ease of use. Everyone wins. Well, we'll see who wins... check out this week's competitions.
User Upload Validation Woes
Thin File's ThinImage wasn't without some pains. It was incorrectly assumed that a call to the session from the PHP scripting language would get us our validated user's credentials. Not so. The Java running on the page is its own instance - essentially an unvalidated user. We're not sure how other Thin File clients get around this security exposure and the Thin File site, nor support, has any documentation on suggestions to prevent anyone from uploading through the applet.
We resorted to a time-limited token hand-off between the page and the applet. A flat file outside of our document root is written with a long, random file name. It contains the user's validation credentials. This file name is passed to the applet, whereby validation is confirmed and the upload is permitted. The token flat file is then destroyed.
This approach works and isn't any less secure than session hijacking. The downside is that user's now have an artificial time constraint on their upload. This becomes a problem only when a user hits the applet upload page, leaves his or her computer for 10 minutes and then returns to upload their photo. Thinking about this problem out loud makes us think a meta refresh tag of 10 minutes that bumps the user to their last visited page would be a good solution. See that? You just read how a feature is born!
Alternative image uploaders
SWFUpload
Pros:
* File size limit
* Multiple file uploading
* File queuing with start & stop upload buttons
* File type(s) limit, including filtering on file browsing
* Familiar, native OS file browsing dialog window
* Beautiful, XHTML-compliant degradation (if that sort of thing turns you on)
* Faster than Java applets
* Free
Cons: (all of these are Flash limitations)
* No client-side resizing
* No client-side manipulation (e.g. rotation)
* Authentication is a little kludgy (Flash cookie bug)
Aurigma
Pros:
* Many client-side manipulations (resize, rotate, watermarking and more)
* Displays preview image on file browsing
* File size limit
* File type(s) limit, including filtering on file browsing
* Multiple file uploading
* Multi-language support
* ZIP compression
* Folder uploading
* Upload resuming
* Nerdy features (load balancing and file pairing stuff)
Cons:
* Most expensive
* Slowest to load
* Ugly, clunky UI (we don't care what their Web site says)
* Facebook uses it (we kid, we kid)
The overall theme and frequency of this blog will be sporadic. We apologize in advance.
This blog will cover events, design decisions and general start-up thoughts related to 52 Clix, a burgeoning start-up created for the purpose of breathing extra life into the forgotten petabytes of digital photos.
So dust off your hard drive platters and upload your snapshots to any of our weekly photo competitions, called Clixies because we wanted to be cute, or create your own competition! (the exclamation point makes the action seem exciting, no?)
Thanks for stopping by.
