Happy April Fool’s day! In lieu of a prank, here’s this year’s horrible pun:
Happy April Fool’s day! Here’s this year’s awful joke:
I replaced an ethernet cable with a live trout. I was expecting catastrophic results, but the worst it did was flip a bit.
These are honey buns. Patriotic honey buns, if the box is to be believed. The obvious question here is, what is so patriotic about them? The answer is nothing, aside from the box featuring a flag, some stars, and the word “patriotic.” Even the individual wrappers don’t have anything special on them.
A less obvious but still relevant question would be, why do honey buns need to be patriotic? They are basically chewy bread products soaked with a sugary glaze. How would patriotism improve them? This is just one man’s opinion, but I believe that we should just let honey buns be honey buns.
I wanted to share this picture anyway, but considering the timing, I’d like to use it to lead into another point.
In the United States, September 11th of each year is a memorial to those who died in the terrorist attacks on that day in 2001. Usually I just hear it called by the date, like how Independence Day is commonly just called the Fourth of July, but it actually does have a name: According to the relevant Wikipedia article, the full name is “Patriot Day and National Day of Service and Remembrance,” but for short it’s just called Patriot Day.
I certainly don’t think there’s anything unusual, much less wrong, about having feelings of patriotism stirred up by the memory of an attack on the United States. Still, if it’s meant to be a memorial, I don’t see how patriotism improves it all that much. I’d rather just let the memorial be a memorial. There’s nothing wrong with love of country, but I don’t think it deserves top billing in the name of the day.
Solving problems can be hard. There’s always a temptation to do something about a problem, even if that something is less than ideal, to meet deadlines, appease stakeholders, or just avoid feeling helpless.
There’s certainly nothing inherently wrong with implementing a partial solution. Solving part of the problem is, all else being equal, better than not solving any of it. In programming, partial solutions are an industry standard: Nearly every methodology I know of is iterative to at least some extent, and at any rate, I’m pretty sure the waterfall approach is not a good fit for any project that takes more than five minutes to complete.
There are other cases, though, when it’s better to wait until you have a complete solution before implementing anything. Take politics for instance: Iteration is extremely slow, as you have to get solutions hashed out by one or more legislative bodies and then probably turned over to other parties for final approval. This all depends on your particular form of government, of course, but if your government lets officials make decisions quickly and without opposition, I’d suggest that you may have other problems. (That’s a discussion for another time, though, and probably another blog.) Depending on the situation, it may be prudent to design a solution that can be approved and implemented in pieces, but in other cases it may be better to wait and come up with a solution that works as a coherent whole, and then work on getting that approved.
With partial solutions, the most important thing is to ensure that everyone knows it’s a partial solution. Thinking that your partial solution has solved your entire problem is one of the many ways to create a bad solution.
A bad solution is one that doesn’t work, or worse, causes more problems. Often, they get implemented without anyone (or at least the decision-makers) knowing how bad they are. Even once you know you have a bad solution, it’s often more difficult or time-consuming to fix it than it would have been to come up with a good solution in the first place.
That, for me at least, is why no solution at all is better than a bad one. When you have one unsolved problem, you have one problem and you know it. When you implement a bad solution, now you have two problems and you may well not know it. In software development, this means increased deployment time and cost, and possibly re-training users. In politics, and probably most other fields as well, you’ll face additional opposition in implementing a good solution: You’ll probably have to work to convince people that the problem isn’t really solved yet, and it’s likely that people will be too afraid of losing face to admit that the previous solution was bad. Another example is the medical field, where the damage bad solutions can do should be obvious, but I’ll leave the gory details to your imagination.
I admit there may be cases in which even a solution that does some harm might help more than it hurts, so arguably a bad solution would be better than none, though I’d think that might qualify as a partial solution rather than a bad one. In general, however, I’m pretty confident in saying that a bad solution is worse than no solution at all. It’s better to put the time and effort into a good solution than to do something for the sake of having done something.
Just a note: I’m going to be reworking my post schedule a bit.
For the most part, I’ve generally been able to stick to one post a month, usually in the last few days of the month. Lately, though, I feel like it hasn’t been working particularly well.
Normally, deadlines make me more productive, but when it comes to this blog, they don’t help for some reason. I think they’re even making things works. For instance, my April post was late, and last month’s post was more like a blog maintenance note that was padded out to a full post because I couldn’t think of anything else.
I’m going to do some experimenting to try to find a rhythm that works better. I have no intention of giving up the blog altogether, but I don’t think I’ll be sticking to a rigid schedule either. I have an idea lined up for my next post, so I’ll start with that and see where it leads.
Thanks for reading!
Several years ago, when I first decided I needed a blog, I decided to try an experiment: I’d sign up for both WordPress and Blogger and use both in parallel for a while to see which one I liked better. Eventually, had things gone according to plan, I would have written a post comparing and contrasting the two services. At that point I would have picked whichever one I liked the most, imported all the posts and comments from the loser to the winner, and stuck with a single platform from then on.
Part of the reason that failed was that I just didn’t blog that often. I’ve managed roughly one post every month since May of 2012, but before that, I just didn’t blog enough to be getting useful data about what I liked and didn’t like about each platform. The experiment, if I’d been intent on doing it right, would have required me to produce a lot of content. In reality, though, I generally avoided writing unless I had something I really wanted to get off my chest.
Of course, I did eventually start blogging more or less regularly, so that can’t be the only reason. I can think of a few others.
The primary reason is that I tried to keep similar posts on the same blog. If I wrote a follow-up post, it went on the same blog as the earlier post that inspired it. If I wrote several posts that shared a category, they went on the same blog, so people looking at the category could actually see the whole category, and not miss half of it because they didn’t know they needed to search two different blogs. This tactic, combined with the fact that I don’t write about too many different topics, resulted in my sticking mainly with WordPress.
This caused a couple of secondary effects. First, when people started finding my posts and following them, it was on the blog where most of the posts actually were. Second, since I was using WordPress more than Blogger, I wound up getting used to it and became more comfortable with it. These days, on the rare occasions when I log into Blogger, I feel just a bit out of place.
Of course, it isn’t entirely by accident that I went with WordPress. There are some ways I prefer it over Blogger.
Probably the biggest one is—or was—Blogger’s unfortunate habit of translating paragraph breaks to pairs of line breaks. I could use the
tag all I wanted in the editor’s HTML view, but Blogger would strip it out and replace it with
. I can be a bit picky about using the right HTML element for the right job, so this was a big annoyance. I just tested it, though, and apparently this is no longer the case. If this change had occurred before I got used to WordPress, things might have turned out differently. On the other hand, even now it seems to have replaced my
s with single
s, but that may be a quirk of the WYSIWYG editor. Either way I don’t feel like dealing with it.
I also like that WordPress has syntax highlighting for source code built-in. It’s possible to add it to blogger, but it takes some up-front work and using it isn’t as elegant. (I normally don’t mind a little up-front work, but not if I can get the same or better results without it.)
One more little thing I like about Wordpesss is that it lets me organize posts into categories and subcategories, whereas Blogger only has tags. I don’t really see the need for WordPress to have categories and tags, but on the other hand it’s nice to have the options.
That’s not to say that Blogger doesn’t have its advantages. For one thing, it’s a lot more customizable. It only has a handful of templates, compared to the hundreds WordPress has, but there’s a great deal that can be done to customize a Blogger template. Blogger even allows for the addition of custom HTML and CSS to the templates, and it doesn’t charge for it. (As far as I can tell, WordPress.com charges a fee for custom CSS and doesn’t allow custom HTML at all.)
I also appreciated that Blogger’s HTML view showed me the actual HTML, or at least something a bit closer than WordPress did. Even though Blogger used to modify my paragraph breaks, it would at least show me the resulting
tags. WordPress, on the other hand, replaced my
tags with a pair of line breaks in the editor, but in the actual post they’d still show up as
There’s also the fact that Blogger is owned by Google and uses the same unified Gmail/Google+ account used by all Google services. Whether that’s a point in favor of Blogger or against it will depend on your opinion of Google, but there’s something to be said for not having to manage yet another username and password.
I suppose this will have to suffice for that comparison post I said I was going to write.
As for the future of this blog, I’ve decided to bite the bullet and move everything over to WordPress.com. I’m importing all the posts and comments (or lack thereof) from Blogger to WordPress. I’ll also be removing the “My other blog” widget from WordPress and renaming the one on Blogger to indicate that WordPress is where all the current content is. Once I’m finished, WordPress will be (for the time being, at least) the canonical home of this blog.
Infinite scrolling, a somewhat recent trend in Web design, is a technique in which long lists of items, rather than being broken into separate pages, are loaded a few at a time via AJAX and appended to the current page. If you’re not familiar with it, you can find more information in a Smashing Magazine article by Yogev Ahuvia: “Infinite Scrolling: Let’s Get To The Bottom Of This.” Ahuvia tries to present a balanced look at the strengths and weaknesses of the technique, but it seems that there are more cons than pros. The comments are overwhelmingly negative.
In addition to Ahuvia’s piece, Hoa Langer’s “Infinite Scrolling is Not for Every Website” says that infinite scrolling “plays a nasty trick” because it “breaks the scrollbar,” and concludes that the technique is “not the answer for most websites.” Dan Nguyen and Dmitry Fadeyev both write about how infinite scrolling didn’t work when Etsy tried using it for search results. There’s even an xkcd cartoon.
I’ll admit to being a bit biased in my selections, but I haven’t seen nearly as much praise for the technique as I have criticism of it. This doesn’t surprise me. Personally, I don’t like infinite scrolling at all. It doesn’t seem to be solving a real problem, at least as far as I can tell, but it certainly causes problems.
The problem that most often affects me personally is the jerking effect that occurs when I try to scroll by clicking-and-dragging the scrollbar. When there’s not a lot of content loaded, the sliding portion (called the “thumb” if the Wikipedia article is to be believed) is fairly tall. As more content loads, not only does the thumb shrink, but the point on the scrollbar representing where I was also moves out from under the pointer. As soon as I move the mouse again, the thumb jumps toward the pointer and the viewport winds up somewhere I didn’t expect. It’s very disorienting.
I’ve noticed that this isn’t exactly the behavior I’ve been encountering lately. Instead, on occasion, I find that my mouse pointer is below the scrollbar’s slider, but it still moves with the mouse, not unlike the way it continues to move even when the mouse slides off it to the left or right. Unfortunately, in my experience, this doesn’t stop the page from jumping around a bit when the new content first loads. Consequently, I still lose my place even if the viewport does end up in more or less the same spot. I’m not sure if there’s a script that fixes it, or if browser vendors have made efforts to accommodate infinite scrolling; Benjamin Milde mentions in a comment on Ahuvia’s article that he sees the above behavior in Firefox but not Chrome, so maybe that’s it.
One especially annoying situation occurs when infinite scrolling is implemented on a page that has a footer. There is something at the bottom of the page, but the user can’t actually read it, because as soon as it’s scrolled into view, it gets pushed back off-screen by the newly-loaded content. Making sure there’s nothing under the infinitely-scrollable column might seem obvious enough, but it does get overlooked every now and then. MorgueFile, for instance, has this problem.
In fact, according to Ahuvia, even Facebook did this (at least at the time that article was written). As I look at Facebook now, it seems like there’s a quasi-footer at the bottom of the right-hand column, but it doesn’t have nearly as many links as the footer in Ahuvia’s screen shot. As far as I can tell, Facebook doesn’t have the footer at all anymore; after several minutes, I gave up on trying to reach the point when Facebook refuses to load any more posts on the news feed, so I can’t say that for sure.
Another issue is that infinite scrolling automatically loads content in response to an action, namely scrolling, that normally doesn’t prompt that action. It’s bad enough that the page is taking action without the user’s permission, but downloading additional content in such a fashion can a problem for people who have slow connections or data caps. Whether this is a serious problem depends on what’s being loaded. Another handful of DuckDuckGo search results won’t hurt much, but another couple dozen Google Image Search results may be a problem. Anyway, I think users would like to decide for themselves how much whittling away at their data allowances is acceptable.
Finally, infinite scrolling tends to create a continuous stream of content with no end in sight. This problem is not unique to infinite scrolling: Some pages on deviantArt (but not others) have back/next buttons but no way to jump to specific pages and no indication of how many pages there are in total or which page is the current one. Neither is it impossible for an infinitely scrolling page to avoid this problem: Discourse, an open-source forum project that uses infinite scrolling, solves it with a floating box indicating the post currently being viewed and the total number of posts in the thread.
It’s worth noting that infinite scrolling (without an indicator like Discourse’s) is often used for things like social network posts and search results for which people frequently don’t care about being able to keep their place; indeed, keeping “a place” in such contexts is often meaningless, because what’s on “page 5" of 10,123” today might be on “page 120 of 11,050” tomorrow as new content is posted and sort algorithms are adjusted. On the other hand, even if the association of a certain page number to certain results is ephemeral, it can still be useful for users returning to the result list using the Back button. Besides, I prefer to be able to decide for myself whether I need pagination.
For that matter, simply using AJAX to implement pagination would solve the problems as well, not add much more friction than the “Show more” button, and not lack much of anything that infinite scrolling offers except the ability to return to previous pages just by scrolling up. A hybrid design could potentially address even that issue, if the feature turns out to be really necessary to some application.
To be honest, I just don’t see an advantage to infinite scrolling. There may be a few minor benefits, but there are other ways to get them, and they don’t justify the high cost of usability. As far as I’m concerned, infinite scrolling is a bad idea and it should probably be avoided.