rc3.org

Strong opinions, weakly held

Tag: Web development (page 3 of 4)

Add some white space

New York Times designer Khoi Vinh has a little advice for Google on the use of white space in Web design. I’m linking to it because I think a lot of Web developers would do well by taking it to heart. It is funny to me that all of Google’s applications have that “designed by a programmer” aesthetic. It sort of makes you wonder how Google is utilizing the talents of the brilliant Douglas Bowman.

Pick one feed format

Nelson Minar recommends that the popular blog tools dump RSS and provide their feeds in one format, Atom. This echoes the best practice established at least two years ago when Nick Bradbury and Sam Ruby recommended choosing a single format for your feeds and sticking with that rather than providing the same data in multiple formats.

I agree with that sentiment and also endorse choosing Atom makes sense at this point. The only remaining advantage for RSS is that it has better name recognition and its name doesn’t conflict with the smallest particle that comprises an element or any of the other things also called “atom”.

Is it OK to require JavaScript?

WebMonkey today asks whether or not it’s OK for Web sites to require JavaScript.

My opinion on this question has changed a lot over the past year or two. Not long ago, I would have said that it’s never to require JavaScript, but I don’t feel that way any more. I think that if your site centers around publishing, you should certainly make all of your content available to users who have disabled JavaScript, but if you provide more application-like functionality, requiring JavaScript for certain features is OK.

As Simon Willison notes, you should always use unobtrusive JavaScript, and progressive enhancement is my recommended approach, generally speaking.

In the end, how you employ JavaScript is a business decision. Developers have to weigh the costs of providing workarounds for people who don’t have JavaScript with the potential loss of revenue from not providing them.

I think the more interesting question is whether or not it makes sense, as a user, to disable JavaScript. Last February I tried an experiment where I disabled JavaScript by default and only turned it back on for specific sites. Disabling JavaScript eliminates an entire class of obnoxious advertisements, and can really speed up the browsing experiment on many Web sites. I found that in many cases, leaving out the JavaScript made Web sites better, not worse. I haven’t used NoScript in awhile, but I still think that employing it is a good idea for most people.

Why not just support HTML?

Seems like there’s a little discussion percolating about whether it makes sense to support wiki-like markup languages for formatting text fields in your Web applications or to just support HTML. I took a position in this debate last year. That position was to favor supporting Markdown.

Here’s what I said:

I’ve basically decided at this point that whenever I write applications that allow users to enter blocks of text to be displayed on a Web page, I’m going to provide Markdown support. It follows conventions that people have been using in text-based email for years, it’s unobtrusive if you don’t know what it is, it plays nicely with embedded HTML markup, and it takes care of turning line feeds in text into paragraph tags in HTML. Best of all, text with Markdown in it is not only readable, it’s eye pleasing. What’s not to love? I’ve been using Markdown when posting to this site for a long time now, and have included it in some applications, but my thought at this point is, why not include it everywhere?

I’d stick by all of those arguments today. I like the idea of the raw content of the text fields in my database being readable before and after rendering, which HTML does not provide. Also, Markdown is not incompatible with HTML, so if you want to use HTML you can.

Also, for any sort of text field, you need to convert line breaks into paragraphs anyway, otherwise users who just want to enter a couple of paragraphs of text are forced to bring their own paragraph tags to the party, and that’s never fun.

The headless browser

Adrian Holovaty is looking for information on how to run a state of the art browser engine in a headless fashion. Basically he wants programmatic access to all of the DOM information that you can get at through Firebug (or any decent DOM inspector).

I don’t know what he’s using it for, but you could use such a system to write an awesome testing tool. I suspect the overhead would not be worth it for most projects.

There are already a bunch of good ideas in the comments. Definitely worth reading.

Mass SQL injection update

Looks like the misreporting of the mass SQL injection attack continues. The exploit is associated with MS SQL Server, not IIS or ASP. It’s confusing because most people run the full Microsoft stack, but the exploit will work against any site that does not prevent SQL injection and uses MS SQL as its database. (This misreporting was most recently seen at the Mass Attack FAQ at hackademix.net and Wired: Compiler.

Also it’s worth noting that the best solution to this problem (noted in the comments on yesterday’s post by Simon Willison) is to use prepared statements to generate database statements rather than building them using string concatenation.

If you’re a PHP developer using MySQL, that means using mysqli. For most other languages, that means simply not misusing your database library. For example, with JDBC (Java’s generic database access library), you can build SQL statements with string concatenation, but it’s just as easy to use prepared statements. There’s a good explanation of how to use prepared statements to avoid SQL injection attacks in ASP.NET at Scott Guthrie’s blog.

I think these days most people are pretty good about using prepared statements for inserts and updates, but they still get lazy and use string concatenation when building WHERE clauses, especially in cases where expressions are added to the SQL query dynamically. When doing so, the key is to go through the process in two steps. Building the statement dynamically but still leaving the placeholders in the query so that a prepared statement can be used and the parameters of the statement can be bound to it properly. It’s a bit more work, but it’s essential for security.

Links for April 19

Usability and performance, part 1

I’ve started collecting screen shots that illustrate the problem of performance issues affecting the usability of Web sites. I saw this one in a shopping cart from an online store (I don’t remember which one, and they probably wouldn’t want to be identified anyway).

As you can see, this text was added to the Web page because the “add to cart” request takes a long time to process. To prevent users from adding duplicate items to their cart, the Web site warns the user to keep waiting rather than pressing the button again.

The proper approach would be to improve the shopping cart so that adding items doesn’t take so long, or to find a more robust hosting provider, but those alternatives are more work and more expensive. I’d be willing to bet that the people running the site are using third party software that they can’t fix even if they want to.

Links for April 9

Links for April 8

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑