drewmclellan

Front-end editing is one of those features that sounds like a good idea, and makes for good demo, but has some fundamental failings.

1) It sets up an expectation for the user that they are editing content on a page, as if they were editing a Word document. But they're not doing that. They're editing content in a system that then happens to be output on that page. It might also be output in other places on the site, maybe in different presentations. This causes weird spookiness-at-a-distance issues where making a change in one places has unintended consequences in another. Essentially you're presenting a metaphor of editing content on a page, but the metaphor is a lie.

2) It encourages the user to think about how the content _looks_ not what the content _says_. This is the same fundamental issue with WYSIWYG editors, where the user wants to make things big and red and underlined. And blinking. The role of a CMS user is to create content. The role of the web designer is to set up the system to publish that content in a way that communicates best according to the site's objectives.

3) The way the page looks when someone is editing on a big screen isn't necessarily how it looks to all visitors to the site. Even saying "this is what your site looks like" is a massive oversimplification. It's not even straightforward to define what a 'page' is on a modern site, and that's only going to get more complex as the web evolves. Trying to tangle your editing interface in with an ever increasingly complex presentation layer is setting the user up for a world of hurt. And lies. Hurt and lies.

It's simply not sustainable, nor a good idea to try to combine your content management and your presentation layer.

I wouldn't blame your host, actually. It's WordPress. It's a shame it's so often given a free pass on these issues when it really isn't good at handling peaks in traffic.

It's probably a good call to shut down these services. Yahoo has to change to survive.

What's not good is the amount of notice. 3 months should be the absolute minimum notice for shutting down a service. Otherwise you lose users' trust and that closes doors on future opportunities.

I used to hate standups when I was at Yahoo. Maybe it's more a sign of how broken Yahoo is than how broken standups are, but the daily process was roughly:

0. 9am, catch up on email, then coast for a while knowing you'll have to stop work at 10am.

1. Find out which meeting room the 10am standup is in

2. Figure out where in the building that room is

3. Travel to the rough part of the building, hunt around for the room.

4. Wait for everyone else to do the same.

It's now 10.20am

5. Stand (OMG the standing!) around for 30 minutes listening to a boring load of status updates from 20 people that have absolutely nothing to do with you.

6. Give your status update (Yesterday I did some work. Today I'll do some more work. What's blocking me is this f'king meeting.)

It's now 10.50am

7. Travel back to the part of the building your desk is in today (if you can find it) and grab a coffee on the way.

That's an hour gone, and it's only another hour to lunch, so no point getting into anything too major. Knock off some smaller to-do items. Lunchtime!

An alien race observing us would conclude that teams were a device used to prevent work getting done.

If a load fails due to network issues, the user won't always appreciate that the fault was down to networking. The site might just look broken.

If the failure wasn't related to a network issue (either bad data, or perhaps a buggy JS interpreter on their device) then refreshing won't help. The site will still be broken.

My point is that we can plan and build in such a way that JavaScript failures don't break the page. It's a little bit more work (doing things well usually is) but a reusable component library is absolutely the right place to focus that effort. Everyone then gets the benefit with no more work required.

The issue Bootstrap still has is that the parts that make use of JavaScript completely rely on JavaScript. If you're on a flakey data connection, for example, and JavaScript doesn't load parts of the page simply break.

The tab component is a good example of this - turn off JavaScript in your browser and you'll see that it still looks like tabs (thanks to CSS) but you just can't access anything part from the first tab.

Technically, this isn't a hard problem to solve. Have JavaScript add the HTML class that triggers the CSS rules to make the content look like tabs. If JavaScript fails, no part of the page ever gets hidden.

It would be great to see Bootstrap embrace progressive enhancement properly. With more devices of different capabilities accessing the web over networks of varying quality all the time, it becomes more important than ever to build robustly and not just for the best-case scenario.

Thanks. The responsiveness was retrofitted by me (not a designer) in 2011. Narrowing a design is easier than widening it.

That's the same design, we just allow the page to adjust to the available screen width.

Thanks for replying. It sounds like your preferred aesthetic is completely at odds with what we're trying to achieve. No harm in that.

As the publisher of said site, an honest, genuine question to you both (or any who share their opinion) - what is it about the site design that turns you off so much? What 'work' does it need, in your view?

(Edit: typo)

That's my site. I'm glad you're a fan - thank you.

I suspect, in this case, that you're simply not this article's intended audience. If you've already got a good feel for design, then the suggestions could feel simplistic.

We publish an article every day during advent. It would be easy to turn out 24 articles that everyone nods their heads to, but it would be really dull and a disservice to our readers. In order to have a really vibrant schedule of interesting things, not every article will appeal to every reader - and that's totally okay.

Today was for developers struggling to know how to make their projects look a bit better. Yesterday was some reasonably hardcore CSS selector stuff. Friday was about designing questionnaires. It's all about variety.

We're happy if any individual doesn't like an article, as long as we're never being dull.

"I've seen this exact same layout on this exact same site."

Dude.

Of course. The comment was "I don't think that any IDE is so costly if you develop on any other phone".

That said, I'd happily pay £500 to not have to use Eclipse, but each to their own.

Just for reference, a quick search reveals that MS VisualStudio can be purchased "from £502" (UK) and a new Mac mini starts at £499.

Keith Chegwin gets stuck in Great Britain, which is probably for the best.

I don't expect them to keep providing a shared hosting service in general. They do, however, have a unique obligation to provide something like it to lifetime customers.

Yes, it was a good deal, for which I got far most hosting than I paid - that was the entire point of the promotion. They needed money up front, I provided it in return for a lifetime account. It was absolutely supposed to be a good deal worth far more than was being paid. I have received more than $200 worth of hosting in 8 years.

I don't disagree that shared hosting is crappy. In fact, Joyent hosting was always crappy, truth be told. After the first couple of years, I moved my sites elsewhere. It was slow and unreliable. I didn't care because it was a good deal, but I needed better hosting for my sites.

How would I rate the service I received before the message? Poor. I don't host anything with Joyent - the quality isn't there.

I don't care about the hosting, in practical terms. I care about the weaseling and dishonesty towards the very people who backed them from the start.

I was one of the original 200 to back TextDrive in with the VC200 accounts. The risk, of course, was that the venture wouldn't be successful and we'd be laying out $200 for less than $200 worth of hosting. If they were successful, $200 would buy a reasonable shared hosting account for life.

Far from being naive and "falling" for the pricing model, my assessment was that

1) 200 shared hosting accounts (one server?) is a completely plausible lifetime offering for a successful hosting company, 2) $200 is a low risk punt, and 3) these are good guys and I think they can realistically make a go of it

TextDrive was a success, now continues to be a success as Joyent, and 200 shared hosting accounts (the state of play when I signed up) should be trivial for them to provide - even if they outsource that obligation to another provider.

I know I wasn't wrong about them being good guys (they are), but that's why I'm bewildered by today's announcement.

It may not be economically viable for them to provide these services now, but it wasn't economically viable for them to start a hosting company until we backed it. That was the deal. Joyent has an obligation to keep these services online, and if that means they need to take a bit of a hit to do that, then that's what they need to do.

Otherwise, I'm unclear how anyone would trust them again.

The very first sentence is why Git is not the new FTP:

> First, create a directory on your server and initialize an empty git repository.

The number of people who deploy sites via FTP who also have SSH access and the ability to install Git on their hosting is small. Most people deploying to the web do not control their own servers.

This is similar in many ways to MarkItUp (http://markitup.jaysalvat.com/), which I've had good experiences with.

One potential pitfall with JavaScript preview of Markdown (or Textile, or any other similar language) is that if you're not using the same script to transform the content at the server side, the final output can contain subtle differences. Not all implementations are precisely equal. If differences do occur, that can be frustrating for the user who just carefully previewed their work.

An alternative (albeit a more resource intensive one) would be to make ajax requests back to the server and have it perform the transformation and return it to the page. Unfortunately, that's probably not going to be satisfactory for realtime previewing.

My personal experience is that the phones are built to last. My iPhone 3G is now 4 years old, and receives heavy daily use from my 15yo daughter. The battery runs all day - it's still totally reliable and doing good service. That's more than I'd expect from a phone after 4 years.

This looks really useful, and the API looks simple.

Just a quick reminder for those using any library like this; screenreader users (typically blind people) rely heavily on the keyboard to use their web browser. Adding your own shortcuts can really screw them over. It's usually best to make your custom shortcuts a feature that the user opts in to, off by default.

> tell them that you may have to fire them or that they may be let go through not fault of their own

This is really great advice. If there's one thing almost as good as being in rock-solid employment, it's having a clear and accurate view on what the stability of your employment position is.

In the source of the script itself, it has:

    Dual licensed under the MIT or GPL Version 2 licenses.

...which is how jQuery is licensed, as is common for plugins and other jQuery-based projects.

Theoretically, adding the following to your browser's user stylesheet should defeat this:

    a { pointer-events: auto !important; }

The !important keyword adds weight to the rule, which trumps origin, specificity and sort-order in the CSS cascade.

A quick test in Safari/Mac confirms that works for this particular case.

Glad he's okay.

Let's hope the hospital doesn't offer him breakfast.

Absolutely. We have code reviews because we all make mistakes. Sometimes really dumb ones.

It's crazy to be mad at a programmer for a bug in their code found during a code review. Discuss it, learn from it, and not only does the code get fixed, everyone involved becomes a better programmer by some small amount.

The only time it's justifiable being mad is if something gets through code reviews and into production - and at that point it's not the programmer's fault, it's the fault of procedure which enabled buggy code to ship undetected. So you get mad at the system, review the failure and fix it.

It wouldn't be unreasonable to suggest that the stress (and business impact) could be reduced by making sure any critical machine has a hot-backup should it fail.

Making sure employees are happy and safe in their work is good business.

Testing in different browsers is a real pain. Getting front end code working properly in all those different browsers is even more of a pain. Getting that code working really well is harder still.

It takes time, dedication, skill, and a lot of specialist knowledge of bugs, quirks, standards and tools.

That's the reason that front end development is a role in its own right, and not just a function of someone else's role.