rmurphey

Why niche networks will flourish and Facebook will flounder

Posted

It was just a couple of months ago that I was naively lobbying my friends to join Facebook. I envisioned creating a place where I could find out what everyone -- especially people who were more acquaintances than friends -- was doing, without the burden of keeping in contact with them individually. Joe was going on vacation? I'd know not to be looking for him online. Corye was studying for a law school exam? No sense inviting her over to play cards this weekend. Then came the applications, and then came the pirates. And the vampires. And the causes and the superpokes and the invitations and the ... well, and the noise. I started to wonder whether some of these people actually had jobs, and I started to visit Facebook less and less. I felt a glimmer of hope when Facebook offered what seemed to be the ability to silence some of the noise, but no matter how much I clicked to hide useless News Feed items, they persisted with a vengeance. Then it occurred to me: I'd blithely assumed that everyone would want to use Facebook the same way that I did -- as a source of information. When applications made it a source of entertainment, its value to me as a source of information collapsed. Instead of being the general social networking site that I'd wanted it to be, and that I think it sought to be, it became a niche network for people who like to spend their time with pirates and ninjas and movie quizzes; in the process, it stopped appealing to people like me who had come to it for the information service it provided. It makes sense that this happened: the internet has been groundbreaking in the opportunities it provides for like-minded people to gather and share their common interests. And that's why, when I was asked the other day what I thought about social networks, I said I believed the future is in niche networks that target specific interests, rather than general networks that try to make room for any and all interests. The concept of critical mass dictates that general networks will become specific, sending the dislocated people packing to search for networks that provide what they want. It's why I'm spending more time on LinkedIn; why an avid reader might gravitate toward Shelfari; why a music lover might head over to Last.fm; and why my game-playing, time-killing acquaintances are still pirate-ing and ninja-ing each other over on Facebook. These niche networks will have more value to advertisers than general networks, too, as sites figure out how to leverage data contained in a person's network to target content and advertising. That two people have established a relationship on Last.fm says far more than that two people have established a relationship on Facebook -- membership on Last.fm indicates some degree of passion for music (which can serve as a sort of prequalification), whereas membership on Facebook indicates little more than ownership of a computer. Just as RSS transformed how people interact with information, allowing people to remix and repurpose websites (or avoid them altogether via an RSS feed reader), the next step in the evolution of social networking -- be it OpenSocial or something else -- is going to transform how people interact with their people. It's going to put the focus on the data, not the presentation, and allow users to remix the data and the presentation to suit their needs. The quality and interesting-ness of the data will dictate which sources a user chooses, and the user will be able to trivially tie together as many of the sources as they want. Facebook, Shelfari, Last, LinkedIn, and all the rest will continue to be destinations for the niches they cater to, and the real competition will be in offering the best data. Choosing a one-size-fits-all site -- and naively inviting all of your friends, hoping they come for the same reasons -- will be a thing of the past.

How I learned CSS

Posted

I remember when I first tried to understand how to produce designs for the web -- coming from the paper-based world, it was hard for me to accept everything that was suddenly out of my control. When I first tried to grasp CSS with the help of now-defunct Adobe GoLive, I bailed pretty quickly. Table-based layout and font tags didn't make much sense to me either -- why did I have to slice up a page into a bunch of adjoining cells, instead of just drawing independent boxes like I did in Quark? A couple of years later, I decided to try again, motivated by the realization that my eight-years-younger brother seemed to be better at this web stuff than I was. I spent untold hours trying to wrap my brain around the difference between margin and padding and exactly how to get floated elements to bend to my will. I remember the epiphany that one could use left-floated list items for a horizontal menu, or that the right DOCTYPE can force Internet explorer to behave more like a real browser. These days, I have an honest-to-god job doing this stuff, and every now and then, someone will ask me how they can learn it too. It all makes so much more sense to me than it used to that it's hard to remember how I got here. In the interest of getting this stuff written down for passing along, though, here are a few thoughts:

The Tools

• A text editor Notepad will do just fine; for a few bucks, you can get TextMate for Mac or the e Text Editor for PC. If you use Dreamweaver, hide everything but the file navigator panel and the code editing view. You will learn nothing from Dreamweaver's "design" view.
• Firefox You'll need to test anything you do in Internet Explorer, but first, you'll get it working in Firefox. Whereas Internet Explorer enjoys mocking web standards, Firefox does its best to adhere to them; plus, it has all sorts of extensions that make it easier to troubleshoot your work.
• Firefox Web Developer Toolbar This has all sorts of useful tools in it, including a real-time CSS editor that opens in the browser's sidebar so you try changes to your CSS and see the results immediately.
• Firebug This is most useful for Javascript debugging, but it has some nice features for debugging CSS as well.
• HTML Validator Incredibly helpful for finding errors in your HTML.

Learning with Firefox

• Ctrl-U will show you the HTML for a page, and with the HTML Validator extension, you can "clean up" the HTML so it's easier to read.
• Ctrl-Shift-E will open the Web Developer Toolbar CSS editor, which will show you the CSS for the page, with a tab for each CSS file. You can edit the CSS in the editor and see the effects immediately.
• F12 will open Firebug. In the top left of the panel that opens, click the Inspect menu item, then move your mouse back to the page itself and click on an element to find out more about it. You can also click on the HTML tab to view the HTML and expand and collapse sections of it to see the structure of the page. Hovering over an element in the HTML panel will highlight it on the page; clicking on an element will let you find out more about it in the Style and Layout tabs of Firebug. (Firebug is an incredibly powerful tool that you really need to play with to fully appreciate. It's a completely non-destructive tool -- you can't hurt anything with it unless you try really, really hard -- so don't be afraid to click around and see what happens.)
• Remember that these days, lots of page elements are built with Javascript rather than with straight HTML. Ctrl-U will show you only the HTML; Firebug will show you the "generated source," including any elements built with Javascript. Firebug also lets you look at the Javascript on a page, which can be helpful when you're trying to understand how something got there.

POSH

Strategies

rdmey refresh

Posted

When I started this about a month ago, I just grabbed a template that didn't look too awful, changed a few colors, got rid of all the pixel-based font-sizing, and hoped that no one would look under the hood until I had some time to do it myself from scratch. With the holidays here, I finally had the chance, and I spent a couple hours this afternoon tearing down the theme I had and building my own. Gone are gems like

...

Using ems for font sizing in css

Posted

A List Apart had a great article recently on using 'em' for CSS font-size declarations, which served as great back-up for some conversations I'd been having among coworkers. (It turns out that people who didn't have a former life in print don't necessarily understand what an em is: a self-referential unit of font size measurement, equal to the height of the capital letter M. Back in the typesetting days, it was a unit for measuring space, especially horizontal space, in the form of an "em dash" (rendered now as —) or an "em space." There was also a sister unit, the "en.") Anyway: I just came across this post, by someone trying to put ems into practice; at the end, he gets into tools for doing conversions from pixels to ems, and it struck a surprising nerve with me. Here's the thing: While I can see how pixel conversion seems useful when you first make the switch from px to em, I think the whole point of using ems instead of pixels is to embrace the concept that, on the web, sizes are relative, not absolute. If you're focused on matching an absolute size in a mockup by converting pixels to ems, the chances seem good that you're dealing with a layout that wasn't intended to work with relatively sized text to begin with, and/or that your ultimate product won't work if the user makes a different decision than you about how they will consume it. If you receive a Photoshop mockup where body copy is 10px tall, I think it's a tremendous waste of time to measure that 10px and convert it to ems -- 10px on my 1024x768 monitor is a far cry from 10px on my 1600x1200 monitor, nevermind on the HDTV sitting across the room. When you're designing and styling text for the web, better to:

• Assume from the start that users will consume your site differently than you do.
• Make decisions in your design, CSS and HTML that will consistently convey the content and hierarchy of your site, regardless of how it is consumed.
• Assume that the user knows better than you what a good base text size is for them.
• Use a reset styleheet — I like Eric Meyer's CSS Reset Reloaded — to set everything to that base size.
• Vary the sizes of elements relatively using ems.

Standards for HTML emails?

Posted

After a couple of attempts that ended not-so-well, I gave up on HTML emails. I advise people to work with someone who's an expert with them, or to at least use templates that are known to work, and then I wish them well. At a job interview I actually proclaimed my active dislike of HTML emails and general unwillingness to muck with them -- I'm not sure that went over so well. The news that Outlook 2007 actually took a giant leap backwards in HTML support seals the deal for me. Still, it's good to read that some people are trying to bring some sanity to the situation. I wish them luck.

My case for standards-based web layouts

Posted

Since 1999, the World Wide Web Consortium (W3C) -- a standards body that tells the world how the web should work -- has urged web sites to use semantic markup for content and cascading stylesheets (CSS) for layout, and to abandon code that combines information and presentation in non-semantic HTML table-based layouts. Semantic markup ...

• puts the most important information in a document at the beginning of the document;
• clearly marks headings, paragraphs, lists and other standard elements; and
• in general indicates what something is, not what it looks like.

• Search engines like pages they can read, and semantic markup using HTML provides a language search engines can understand. Mark an element as a Level 1 Heading, and search engines will know it’s the most important heading on the page and use that information to figure out what your page is about. Simply using semantic markup can contribute greatly to a site’s search engine optimization.
• Accessibility has come to the forefront of the web development world with the certification of a class-action lawsuit against Target department stores. The suit says that Target has refused to take steps to make the site usable by people who are visually impaired. As a result of a ruling in the lawsuit, California may mandate that sites be accessible to the visually impaired. While sites that use table-based layouts aren’t inaccessible by definition, they are inherently more difficult to make accessible than sites that separate their information from their presentation.
• The Web 2.0 phenomenon relies on content that can be rearranged and reused with ease, and that rearranging and reuse is infinitely easier on sites that separate information from presentation. Web 2.0 technologies rearrange, reuse and repopulate elements on a page based on what the elements are, not on what they look like or where they are on the page. As users come to expect more interactivity and fewer page loads from their web experience, sites that separate their information from presentation will be in a better position to make use of Web 2.0 technologies.
• The mobile web has existed for several years now, but the iPhone is reshaping the mobile web landscape and blurring the line between PCs and portable devices. Though the iPhone can browse “normal” web sites, many content providers are offering sites that are HTML-based but customized for the shape and size of the iPhone’s screen. As more portable devices that can browse the “normal” web become available, sites that separate content from presentation will be uniquely positioned to offer mobile users a customized version of their existing pages without having to change the underlying code.

• POSH - Plain Old Semantic HTML on 456 Berea Street
• Why Tables for Layout is Stupid from Seybold 2003 (!)
• The W3C on CSS
• CSS Zen Garden, the site that leads many developers down the path to standards
• A List Apart offers excellent articles on standards-based web development