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.