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.
1.) There are some pretty nifty frontend editing demos that show you what the site will look like on desktop, table and mobile at once, I don't see that as a big problem. Don't really agree with it being a metaphor since most front-end plugins literally make the actual content editable on the frontend.
2.) Agreed on the formatting. But you can limit content editors by restricting the available tools and formatting options. As for the looks vs says, I think it heavily relies on the person. Some people are visual beings and perform better when they are seeing their page being built as opposed to created in a detached vacuum.
3.) #1 adresses this in part. As for complex content, we've had pretty good feedback on using blocks with visual previews on the frontend. There are issues, such as very large blocks having problems with drag-and drop, but I think these are just hurdles.
From a programmer standpoint, I guess it would be nice to detach the content from the presentation, but working "IRL" with business owners, creatives and journalists I hear almost every day about the "complicated systems" that people want to get rid of, opting for a simpler, visual experience.
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.
Using the popular caching plugins...W3 Total Cache (http://wordpress.org/plugins/w3-total-cache/) or Super Cache (http://wordpress.org/plugins/wp-super-cache/) seem to be well liked and I've used both of them without too many issues (I have some weirdness in my WP upgrade path). My blog has been on HN and reddit a few times and has never crashed, even though I'm on the cheapest Dreamhost hosting plan with what seems like 5 to 10 second response times for non-cached pages.
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.
Wow, that's like a zoo of process pathologies. In order, the things I see:
I like doing the stand-up as early as possible, so that there's minimal slack time before hand. And I prefer to work in ways that are less dependent on the state in one's head, including test-driven development and pair programming.
The standup is always in the team room. Everybody on the same team works in the same room. Generally, you do it in front of the kanban that shows the state of the project.
Because it's right where everybody works, it's pretty easy to be on time. Regardless, it starts on time. No waiting for stragglers; it just encourages them.
You stand for 10 minutes or so.
The team is some reasonable size; I think of 12 as a maximum.
If the people turning up have nothing to do with you, then it's not actually a team. Teams are groups of people that win or lose together. Team members help one another out to achieve shared goals.
If what people say is boring, you should be able to tell them so. They are there to talk to the team; there's no point in them saying things that aren't useful to the team.
Coffee should be in or near the team room. Ditto water, snacks, and other things necessary for humans to do work.
The stand-up should be run in such a way that people leave ready to jump on things.
If I had to guess from your description, I'd say that Yahoo took a top-down culture, pasted on some Agile rituals, and kept right doing the same old bullshit. Which, honestly, is a giant waste of time. If you're going to do waterfall in a command-and-control context, just do that. No sense putting agile lipstick on your waterfall pig.
We use on-line standup meetings. Notice people are meeting in the Teamspace standup room, click in, chat briefly until all are there (about 30 seconds). Then call out your issues and blockers round-robin for a few minutes. Then click backto your home office.
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.
I disagree. As a web designer/developer your job is to make sure your site looks proper. If someone chooses to disable javascript, they know that they are missing out. It's their personal choice to embrace an inferior web experience, and I don't think it's fair to have to compensate for them as well.
...except that JS can also fail due to network lag or simple programming errors (like a trailing JSON comma in IE). Ideally, sites should remain as functional as possible if JS or CSS fail to load. (Admittedly, a great many large websites fail this test.)
Requiring a refresh is not outlandish. If they failed to load the content due to network error, they will already be used to that kind of flaky connection and the refreshes it requires.
Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.
Why provide a usable but substandard experience when those users would get a superior experience after a simple refresh?
As for the "turned it off crowd": in terms of web apps, who cares? If you've disabled Javascript, you're not looking to use web apps -- period. Javascript is required to use web apps for anything other than fancy form posting...
Of course, every site's audience is different, and you should prioritize your development for your audience.
It's annoying when you're using a different device in a locked down environment to have to deal with pages braking because some JS (or other) won't load on whatever piece of junk browser or device I have to use. I had this issue a lot when traveling through Asia, I never realise how bad accessibility was until I had to use crap phones and dodgy computers to access airline websites.
For the love of god please provide a BASIC fall back!
Slightly adhomien edit, but I think you're ignorant and live in a bubble. Not everyone uses their computer, or has the same level of access, like you do.
What you call a bubble, I call my target audience. I don't mind that I accurately target my audience and prioritize my development towards them.
If information is what you care about and not design, style, or functionality, than my pages are perfectly readable on a screenreader. It will look and function like shit but the people who see it that way A) expect to or B) are not my target audience.
But you're right, it's a bubble. If my audience included people with poor data connections in Asia, then I would certainly approach the problem differently.
However, when it's just one guy making something, prioritization and cutting out the nonsense (like bad connections from Asia) are vital ;)
If any of your target audience may use your service from a less than desirable connection or device then you should try and make it as accessible as possible. Falling back to non fancy CSS and JS is vital.
It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?
>It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?
Because they wish to offer any form of rich experience that goes beyond form elements and form submission? Because they want date pickers, column sorting, marketing tracking, transition effects and a hundred other UX tweaks that are only possible through javascript?
Why should airline/online travel forgo modern user experiences? To satisfy a statistically negligible amount of their traffic that cannot see it?
At some point, horses aren't allowed on roads, and users need to buy a car.
They can still have all of that for most of their users. Users that can't use these newer features should be offered a simpler more basic experience. Just because it's a minority of users that want to access your medical claims portal from abroad (who'd have guessed that this would be a valid use case for someone who has bought world wide health cover?) this doesn't mean that you should lock them out.
You are very short sighted. I hope you end up in a position where you need minor surgery in Vietnam during your gap year and can't enter the claim in the insurance companies system because they insist that ALL user must be able to see their fancy drop down menus with rounded corners OR not being able to book an onward flight from Cambodia therefore being refused entry because you can't prove that you plan to leave in the next 3 weeks all because the internet kiosk you're using is blocking the CDN that pushes some crap JS that adds nothing other than eye candy.
What's wrong with creating an alternate UX without all the overhead?
I hope you suffer the consequences of your own short shortsightedness.
Also, FYI, horses are still allowed on roads.
EDIT (can't reply) I think you'll find that medical insurance sites and travelling / booking sites are very similar and attract a very similar userbase. People book flights ticket and medical insurance, people fly then use the medical insurance when they have too. You seriously do live in a bubble, i have a feeling you are an American who isn't very well traveled outside of his own country and only uses medical sites in the context of your non state health insurance. You probably aren't the kind of person that would use any of the services I care about.
SECOND EDIT.. I spoke about my two target services from the offset and did not switch context. Do you not realise how these two sites / services go hand in hand?
I just got back from skiing. I used an airline site and medical insurance site for the same trip.
Haha. We went from talking about my 1-man development website, to travel sites, to medical sites.
All because each example is a better fit for your argument. You don't warn me when you change the context of our conversation, you just do it and then insult me afterwards for not meeting your newer demands.
Medical =/= travel =/= my site.
Each are fundamentally different industries with dramatically different requirements. Obviously you have to meet the requirements of your industry and your users. I have CONSTANTLY SAID that you must prioritize your users. Medical users ARE NOT travel users ARE NOT blog users.
You're also failing to take into account a team versus one man. One man or small teams trying to launch have to prioritize their MVP and their main audience. Massive operations with dozens of developers SHOULD meet everyone demands, because they have the time and talent to do so.
When you're capable of not context-shifting a conversation to continually cast your argument as superior, I think this chat can continue.
Otherwise, you're just shifting and insulting me for your own jollies, and you'll excuse me for not going along with it.
Good day!
EDIT to your EDIT:
I currently work in healthcare IT after transitioning from a major travel IT company. The requirements are NOTHING alike, really nothing alike at all. The types of users and the requirements placed on the organizations by regulators are dramatically different. Medical is a WHOLE different ball game with tons of people to answer to.
Also, people can be expected to not book a plane flight with a bad connection on an old phone. "Wait until a better connection" is the standard response that has worked thus far (or call your secretary/company to handle it).
When it comes to medical data, waiting is less of an option and getting a good UX is less of a requirement.
Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.
Wait for a better connection... oh yeah sure, I'll just go look for another internet cafe in the middle of nowhere on my travels.... Seriously, you're an idiot.
So many companies get this right. A few don't. I serioulsy hope you suffer
EDIT: I'm specifically referring to people that travel here. As you live in a bubble, I doubt this applies to you or the sort of work you do.
>Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.
That is the most superficial comparison between two disparate industries that I've seen in some time.
Yes, both are websites that you access.
By this context: I visit mobile gaming websites from foreign countries. According to your analysis, mobile gaming == travel industry == healthcare.
You do, of course, realize that the regulation requirements behind the systems that deliver those websites are dramatically different?
Between HIPAA, ARRA, a bevy of other national regulations and 50 separate state implementations of Medicare/aid with additional privacy and other regulations on the state level, I hope you can appreciate that medical software requirements are fundamentally different.
Implementing a medical portal is an order of magnitude more difficult than a travel portal from the regulation and control side alone.
Put it this way: if you leak user data on a travel site, all you might have to do is write mea culpa and force a password change.
If you leak user data on a medical site: the fucking hammer comes down, public disclosure is mandated and _heavy fines will follow_.
These kind of systemic differences absolutely affect the end user UX and the kinds of priorities that developers have going into it.
Making sure spotty data connections work is less of a priority than making sure a secure connection is present when dealing with HIPAA protected data.
All I'm saying is... websites and portals that are accessed from devices and connections, in emergency-ish situations, should really have fallback modes so they work when I'm stuck in immigration in a third world country (or hospital).
long haul airline sites and medical insurance sites fall under this category. I'm not talking about this from any other perspective than accessibility under less than desirable conditions.
I don't really see how this has anything to do with American state laws. Accessing a portal that tells an insurance company that I need treatment abroad is a simple. Can you please burst your god damn bubble. We're talking about JS and CSS fallback not the united states of americas various laws in regards to medical records.
Yes, sites whose main audience may view it from those limited connections should devote resources to ensuring that they can access it from limited connections.
I clearly stated exactly that in my first original post in this thread. I said, always know your audience and prioritize your development for your audience. I don't know why you've missed me saying that 4+ times at this point. I guess it's because you want to "win" a debate, even though I made your point before you even read my original post.
>I don't really see how this has anything to do with American state laws.
Because accessing data requires you follow the laws governing that data regardless of where the request comes from.
>Have you ever left the US?
Have you ever programmed before? Do you know what software requirements are, or legal requirements, or any of it?
Honestly, you sound like a layman. 100% end user with zero experience in building a portal or medical software or anything else. "Who cares about laws, I'm talking about css fallback". Well, the people who pass and enforce those laws care, even if you don't. And they will make sure you care sooner or later, if you plan on staying in business.
That's the point. You have to care about laws because they're fucking laws! You don't get to just distribute protected medical data over insecure connections because it's convenient for end users! That's illegal.
And protected medical data IS DIFFERENT from non-protected personal travel data!
I know that understanding that difference is difficult for an end-user, but please respect that the concepts are completely different and pretending that "it's the same" only hurts your ability to understand the additional complexity that security laws like HIPAA introduce.
Please do not talk to me any more. I have no interest in replies and have provided this one because you keep stalking me in other posts, so I wish to provide closure.
If you want the last word, please take it here and no where else.
Please stop following me and posting on unrelated threads, it's extremely immature.
You're an idiot, I'm talking about the accessibility of a data entry portal. There's no reason to not make it work in sub optimal conditions if ANY (not just your main) of your user base are likely to be in those conditions.
This has very little to do with data protection laws. I'm not talking about making your data secure, using ssl, redundancy in your database etc. These are all requirements but this is not what I'm talking about.
Simple accessibility in sub-optimal conditions. Stop trying make your small minded opinions the focus of this. Do you even own a passport?
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.
I agree that the NoScript folks can be ignored for apps. However, for web sites which consist primarily of rich documents, it's polite to at least try to convey the same information.
> Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.
Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".
Also, not all users will understand that components didn't load (many users still don't even know what a browser is!). And if the failed load is due to a proxy/firewall/DNS problem, or just a straight-up bug, a reload may not solve it anyway.
In any case, you're spot on about prioritizing development to the audience. Guidelines can be a good start, but there's no "one size fits all" for the web.
>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".
Should you devote a lot of your limited programming time to catching an exception that users naturally experience during USB operation and can be corrected by a simple "unplug and replug?"
I argue that you shouldn't devote undue attention to something that users naturally already handle.
But if your project is healthy and features are rolling out and you have the time and talent to waste on edge cases like this, then why not!
It is totally fair unless you're creating a web application but my idea is that the first priority of a content-heavy web site should be to make its content as accessible as possible. Also, inferior experience should not mean they miss more than half the content.
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?
I'd suggest removing all the 'complicated' layering effect and transparencies. Even hovers over the year links are creating transparencies on the article text. Just leave the article text area 100% opaque, lighten the background to improve contrast. I want to read easily and not off a weave basket.
There is a tad too much variation/combo of the colors used. You have red and grey (which is good) but you have a gazillion shades of it (not good) and you have them alternating roles, ie: red text, red box, grey text, grey box, dark grey text, dark grey box - tighten your color usage. Since your colors usage are everywhere, there's no accent color. (Like I can't tell which color is used to declare text links since all text colors can be text links)
The red is a very strong color - and since author box is in red, it's competing with the article for attention (the article should be the main focus. But it doesn't mean you should make the article box red.)
Move Date under Year (navigation) or move the year next to date - don't make the readers' eyes/brain work, trying to correlate the 2.
Don't show links that aren't clickable and will never have content. ie: Year 1999 etc. Just start from 2005.
Overall the page is super busy with its big range of color shades, layering with transparencies and confusing visual hierarchy/navigation.
Just as another opinion, I love the design of the site. I saw 24ways a couple of years ago, was truly amazed at the "different" design. I still think the same design is truly unique and captivating.
Just to get some other opinions out there.. It would be nice if it responded more for large screens instead of only handling the small ones, but I love the look of the site.
For me it is all the watermarking effects, with background and foreground elements becoming merged. This creates a cluttered effect needlessly, because without these I think the site would be a lot more pleasant to look at with no other changes.
The big red site title at the top is obscured by the "HOME", "ARCHIVES", etc. boxes below it to the point that it's actually difficult to read. The color choices in that section make everything hard to read. It's not important (I come for the content, not the site title) but it demands attention by taking up half the page and containing horribly clashing colors.
It's just far too busy. There's a white button title on top of a semi-transparent gray button which is on top of a darker gray background which is on top of big red letters which are on top of some sort of weird faux-paper diagonal strips. It's like there was an explosion in the layer factory, and it increases the effort needed to actually read the text beyond what I'm willing to put in.
I also wouldn't do exactly the same thing regarding the transparencies (maybe kill the extension of the year/day highlights behind the primary white-ish content area, and just only have those highlights be visible in the framing area?), but my first reaction was actually "oh, cool, a site daring to have a bold design and go its own way instead of trying to look 'beautiful' like most of the bland sites posted here."
So don't tone it down too much. You can't please everyone, and there's a big design echo-chamber on here. And actually, on second thought, maybe I wouldn't change it at all. Be bold and distinctive. Own it. Design isn't about toning stuff down to the lowest common denominator.
And I love the ease of navigation provided by the top year bar and side day bar.
For what its worth (and I'm no designer): I really like the mobile version of your design. The text is easy readable, the sections clear and there is no annoying clutter.
He definitely means once all the weird column/row effects and text are gone. The site becomes simply, with your header, your content wrapper, and the content. It's a lot nicer at that point.
The longer I look at the desktop version, the more I like it, but my first reaction was not good. It's too much. (I'm a hacker, not a designer, btw)
When I said "ugly site" in my original comment, I meant from the perspective of a person leaving vitriol on the thread here. So, ugly to them, not to me. I realize now on second read that probably isn't clear, but I have to let it stand. Forgive the seemingly-direct attack.
I think your site is visually striking, but it's a wee bit busy for me. That's all.
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.
Just wanted to say thanks to you and your contributers over the years. I always thought 24 articles in 24 days was a very ambitious idea but somehow you guys always deliver the magic.
I'm not the target audience for this article either so it really is hard to judge, but I got something out of it and I can see that a number of people found it helpful and timely.
Or you use Visual Studio Express C# which is free.
Visual Studio (payed) combines all tools, all languages together and works with git, sourcesafe and many, many things more.
Or if you're a startup, you can receive all Windows stuff for free ;) (so you don't have to pay)
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.