Tag Archives: webdev

Trying to get at the features left out of the mobile app

I use extensive filters on Gmail to categorize mail the way I want. I pre-filter some things to look at later, prioritize some lists (like allergy or uptime alerts), and pre-categorize things that I may want to file away after looking at them.

The problem is, I can only change filters on the desktop site. When I’m reading on my phone, I need to remind myself not to archive or delete messages that I want to start filtering.

It occurred to me: I can label those messages “Change Filter.” I could even do it right away – there’s a “Manage labels” option on the Android app!

Nope!

I can’t add labels in the app, just change the download and notification settings for each.

So, website then…

Except I can’t get at the full Gmail website on my phone. Or my tablet. Google insists on showing a stripped-down mobile site, which has even fewer capabilities than the app.

I can’t fault them for starting with the mobile site. It is helpful to focus on the features that work best on small touchscreens, under-powered processors, and high-latency, low-bandwidth networks, and can be done by someone on the go, rather than someone sitting at a keyboard with a big screen and a mouse.

But if someone wants to use the functionality you’ve left out, and is willing to slog through the desktop site on their phone or tablet, you should at least let them get at it!

In this case I waited until I could log in on a desktop, then added the label. But not everyone with a phone has a desktop or a laptop. And as the balance keeps shifting towards phones as people’s primary internet access device, that’s going to be more and more common.

Webdev Tip: ALWAYS Put the Record ID *in* the Edit Form

I started out this morning happy with my web host. They’d sent me an alert about disk usage that allowed me to catch an error that would have filled up all the available space on my VPS and taken down this site and several others, and I was able to fix it before that happened. That changed as I discovered what had actually set it up, as revealed by another, more pressing issue.

Background

A few months ago, my VPS did lock up, because I’d set up backups on a new site and forgot to add a cleanup script. Tech support brought the server back online, I cleared out the backups, and I copied the script over from this site.

But this site’s cleanup script stopped running, and it reached 90% usage. The script was there, but the cron job was somehow pointing to the other script. I figured I must have messed it up at the time, made sure it was correct now, and moved on.

Discovery

Later this afternoon, though, I discovered that a test blog I set up last week was pointing to the wrong site. That seemed really weird. I looked in the control panel and it was very neatly pointing to the other site’s folder. How does that happen?

Then I remembered: A few days ago, I’d reconfigured several sites to upgrade them to PHP 7.2. I’d opened them in multiple tabs to I could get them all at once. And I had this sinking feeling.

Sure enough: DreamHost’s control panel doesn’t put the form state in the page. As far as I can tell, the ID of the record you’re editing is stored in the session somewhere, which is fine if you only ever have one page open at a time, but if you open two pages, it gets confused.

That’s what probably happened a few days ago: I opened two forms, saved them both, and the settings for one site got written to the other. And it’s probably what happened a few months back with the cron jobs: I opened one to edit, the other for reference, and it overwrote the wrong one.

As near as I can tell it’s just the one site that got messed up, which is a relief. Even better that it’s the test site and not, say, this one. But I’m still waiting for the fixed config change to take effect.

Lesson

Always, always put the record ID for an edit form in the form. People will open multiple records in different tabs or windows, to compare them or just to speed up their workflow.

If you store it in session, or in a cookie, or anywhere else, you run a good chance of saving the data into the wrong record.

Recent Links: Geography, Internet and Comics

A few interesting links that I’ve been meaning to post for a while now.

Geography and History

Using and Building the Internet

  • Warren Ellis has given up on Facebook and Google+ because it’s just so hard to reliably reach or listen to people. Think of how many posts in your news feed you miss each day just by not being online at the right time, never mind the pre-filtering Facebook does to the firehose.
  • Page Weight Matters – an engineer at Google led an effort to cut Youtube’s bandwidth requirements by a factor of ten. Strangely enough, when they started a live test, average page load time went up. It turned out that people on low-speed connections had found out about it and started using it even though it took two minutes to load where they were…because even that was still better than the 20 minutes they’d been stuck with before. (Via Raymond Camden)
  • If you run an email newsletter, keep in mind that many of your readers will try to read it on a phone. Keep that in mind when designing your format. Giant images with no text aren’t going to be too helpful.
  • How to keep electronics going when you lose power for days: Generators, batteries, car chargers, solar or kinetic chargers, etc.

Comics

  • Some of the earliest UNIX daemon art was drawn by none other than Phil Foglio of Girl Genius fame.
  • Saturday Morning in Front of La Salle De Justice is a painting by Rey Taira in DC Comics’ gallery show, inspired by Seurat’s famous painting Sunday Afternoon on the Island of La Grande Jatte (the painting at the center of Sondheim’s Sunday in the Park with George), but recast with the Justice League and other DC Comics heroes. It’s making the rounds again now, but I first saw it on Firestorm Fan a few months back.

Webkit display:table-cell Problem

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.

Comic-Con Hotels 2010: Reviewing the Reservation Form

It was fast. Anticlimactic, really. It took a few reloads to get the Comic-Con International home page up, but once I could click on the reservation link, everything went smoothly. I was done by 9:05.

The reservation page was actually optimized!

  • Just one image: a banner across the top.
  • Everything was on one page, including the list of hotels, the personal info, and the hotel choices.
  • Hotel selection was done by client-side scripting, so there was no wait for processing between selections (and no risk of typos confusing their processing system later today).

This is a huge deal, especially compared to Travel Planners’ horribly overdesigned 2008 forms — yes, forms, plural — that kept bogging down. (I never even saw last year’s, though I tried for an hour and a half to get in.)

On the downside, that one page does load a half-dozen script files, but that doesn’t seem to have slowed it down much.

In case none of your 12 choices were available, they asked for a maximum price you’d be willing to pay for another hotel that’s not on your list. I vaguely recall this being a feature of the old fax forms, but I don’t remember being asked this on the phone last year.

I was surprised to find that they didn’t want credit card info immediately, but that’s good from a streamlining perspective as well. The hotel choices, room type, and contact info are critical in order to make the reservation in the first place. Payment can be done later, so in a rushed situation like this, it’s better to handle it later. Plus, not asking for credit card information means that they could run the site without encryption, speeding things up a bit more.

I would have liked to have gotten a confirmation number for the request, or an email, just so that I could be sure that I was in their queue. And to be sure that I entered the right email address. And the right start and end dates. And…well, you get the idea. I’m a little paranoid about the process at the moment.

Here’s hoping that the back end of the process, and sending out confirmations, goes as smoothly as the front end did.

Update: Short answer: it didn’t. Long answer: I’ve written up what went wrong, at least from the guests’ point of view.