(Note: I'm crazy busy right now, so I cranked this off as quickly as I could and am posting without any proofing. So forgive me if it's a little more rough than my usual.)
The first major update to the new beta site was posted earlier this week. Jason, the guy in charge of tech and product, had a rundown down of the changes here. Discussing the changes over at the beta site, Mokurai answered a question about focus group testing of the site by saying:
This right here is the focus group. All of us.
The concept of the open beta couldn't have been better summarized! You are all the most effective focus group ever assembled, and have already had incredible influence shaping the new site. Let me show you exactly how, and I'll do so by giving you detailed insight into my last two days:
Elfling and Jason have both been keeping an exhaustive list of EVERY bit of feedback from you guys. I'm not talking stuff like "I hate change", but constructive feedback, and even non-constructive feedback as long as it contains specifics. That's the key: specifics.
On Wednesday, as soon as the new batch of changes were uploaded (lots of bug fixes and a new right-hand column), Jason and I met in the conference room to review the current feedback, item by item. And we then spent two whole days on that review, exhaustively reviewing each request and deciding what to do about each one. We took a multi-prong approach to that evaluation:
1) Was it technically feasible, and if so, was it feasible in a reasonable amount of time? After all, we have limited resources and an endless to-do list.
2) Was it desirable, given the broader goals of the site (increasing engagement and readership in order to grow our movement and political power).
3) If a problem was legit, was the proposed solution actually the best solution to the problem. One of the great things Elfling has been doing is drilling down to people's objections to find the root. Oftentimes, people use the current site a certain way as a hack to overcome a limitation, when other approaches would be far more effective.
So the good news is that you guys will get about 80 percent of what you want, but of course that doesn't mean everything. Let me discuss in greater depth below the fold.
Some of the things that are coming:
* More formatting buttons in the publisher (both story and comments). We're adding things like subscript, superscript, numbered lists, TT type, and three header sizes.
* Resizable story- and comment-embedded images. Note, this is a big dev load, and will significantly add to the time before we fully launch the new site. However, we determined it was worth the effort and delay.
* Tweaks to text formatting (spacing, etc), both for story and front pages, but also for comments. The new comps look great, actually.
* New comment markings. This'll be cool, with the ability to use hot keys to jump to next unread comment.
* Cool feature that will mark a comment as read ONLY if it shows in your browser window. In other words. Say you start reading comments, only get halfway, then click off to read something else. When you return, the second half of the comments page will continue to be marked as unread. Currently all comments would be marked as "read".
* Enhanced emoji handling. Love 'em or hate 'em, they are part of the modern world, particularly with younger Americans who we need to better engage. Don't let me see you shaking your fist at the clouds! You're not that old and grumpy!
* Clearer comment preview screen. Right now it looks like comment already posted.
* Lots of additional bug fixes.
Two of the big things that AREN'T coming will also be two controversial ones, so let me explain them a bit:
1. No HTML in story publisher. No modern publisher allows HTML, both because of security concerns, and because it complicates a publisher. Our goal is to expand access to our tools, not restrict them to a small number of people with certain expertise. And no, adding a button to an HTML version of the publisher isn't a solution, it actually amplifies the problem by adding complexity. Modern user interface design is about removing buttons, not adding them.
We took some time to dig in and figure out WHY people wanted this HTML access, and we came up with two big use cases.
a) Special characters and text formatting. Some people don't like to click on buttons, so they memorized the HTML codes for special characters and text formatting options. Well, the new editor allows you to use accepted formatting keywords to do things like bold, italics, etc, just as if you were using a word processor. For example, on a Mac, "command-B" is the common combination for bold in word processors. Well, it now works in the Daily Kos publisher. Much easier than typing out the HTML bold open and close tags.
As for special characters, your operating system has codes or a way to access those, so everyone is better off using those. So on a Mac, if I want a ń, I just hold the letter "n" until a little pop up emerges with special "n" characters. Same thing on iOs devices. Don't know how to do it on PC or Android devices, but point is, those are baked into modern OSs. You get the benefit of learning how to use those special characters in all modern apps, and we get to run leaner, cleaner code, which also benefits you in terms of load times and site speed.
b) Precision layout. We found that people use things like tables in order to create exact page layouts. Seems cool in theory, but it is literally impossible to do that in the modern web. The reason? The near-endless list of screen sizes and resolutions now available, from the biggest-monitor desktops, to the smallest smart phones (and everything inbetween).
In sbort, there's no way you are designing something that will look the same in every device. Our default test layouts and image sizes are optimized to look good on all devices. You start tweaking that stuff, and I guarantee you it will look broken on another screen. Even worse, that big desktop (or even laptop) monitor you are using to write your latest masterpiece is a minority in the modern web. About 2/3rds of our readers now consume Daily Kos on a smartphone, and that number is growing exponentially with no sign of abating.
So if our goal was to help you create a layout that looked beautiful for you and only you, then sure, we'd continue to allow the sort of flexibility that raw HTML allows. But it's not. If you want that, compose your piece in MS Word, print it out, and thumb-tack it to your wall. Our goal is to give you a megaphone to reach a huge audience. So think of our no-HTML rule as a battery in your megaphone. Without it, it won't work. You'd just be speaking to yourself.
Indeed, one of the challenges in allowing resizable images was figuring out how to do it in a way that still worked for all screen sizes down to the phone. We think we have a solution. Once implemented, we'll all get to test it out and see if we pulled it off. But that is ultimately the challenge: having your works translate to the myriad ways that people consume web content today.
This also means that groups won't be able to use their existing crafted group headers. We are sensitive to people's desires to brand and explain their groups. One of our top priorities after the port (along with new direct messaging, improved search, and enhanced story streams) is a more customizable group home page. My preliminary ideas are to minimize Daily Kos branding, boost group branding, and allow for customizable page colors (backgrounds, link colors, headers, etc), dedicated group ABOUT page, etc. I want to give people the ability to have as much of a personal identity while still being integrated into this site's great community. It'll be a big project, and one that I hope to pull together with a committee of group managers. But that's obviously a bit down the road.
So more immediately, we feel that we do have enough tools to enable you to still create a nice group header, and we're going to have our designer work up some ideas on what you guys can do. It won't be as full-featured as you get now with raw HTML, but we won't leave you completely high and dry.
And remember, what we do give you will allow your group diaries/stories to look good on all devices. Right now, some of your stuff looks terrible on mobile. It just breaks.
The second big thing we won't give you is actually related:
2. No story preview. The current publisher doesn't have an intermediary preview page. You can either save or publish and that's it, inline with current web trends.
Again, we dug into the motivations of people wanting preview, and we found two big use cases:
a) People want to verify page layout. See above. That wish is obsolete in the modern web. There's nothing we can do about that. You cannot test for layout given the myriad numbers of screen sizes and resolutions. You'd only be testing for layout for your screen, and that wouldn't just have limited utility, but it might give you a false sense of security because what you see isn't what everyone else is seeing.
b) It's easier to proof when you clear out formatting tools. I am particularly sensitive to this argument since it applies to me. A preview page looks differently to me than the edit page, and I catch lots of mistakes and language usage problems that I can then go back and fix.
We still won't implement a preview page, but we're mitigating this second concern. First of all, the lack of HTML and a true WYSIWIG (what you see is what you get) view allows for a cleaner proofing experience. You don't have to plow through code to ensure your words are well written. We will also remove the formatting buttons when you click out of text box, so the page looks closer to final format.
It's not a perfect solution, and I myself will have to adjust. But the benefits in ease of use should prove worth it. So all I ask is that those of you who are like me and use preview for editing, that you give this new way of doing things a shot.
Incidentally, we're keeping preview on comments, but for a different reason: comment preview was implemented to give people a moment of reflection before posting something they might later regret, as well as give them one last chance of editing before posting. While stories are editable, comments are not. Since I'm still not convinced that editable comments are a good thing (I think they'd be corrosive, actually), this is the only way to give people that ability to reconsider anything they might want to post.
In fact, comment previews were added specifically to slow down flame wars, and believe it or not, it worked.
In any case, I hope you take away several things from this:
1) We are literally taking every single bit of feedback into consideration. No suggestion is ignored or wasted. And even when we decided to do against what you want us to do, it is only after an exhaustive examination of our options and any possible alternatives. We take your concerns extremely seriously. I can't overstate that enough.
2) As you can see above, when we decide against you, I am committed to doing my best to explain the decision so you understand our motivations and concerns. You may disagree with our arguments in the end, but at least I hope you appreciate that we have our reasons as well, and that we didn't lightly dismiss your concerns.
3) The bulk of your concerns are being addressed! I'd say about half of those fixes on the to-do list were already on our radar, and you helped push us into action. But the other half were truly new to us, we saw your concerns, we considered the motivation behind those concerns, decided they had merit, and then figured they were technically feasible to implement.
So thanks a million to you, my favorite and most-effective focus group ever, for helping get us to this point. I look forward to seeing how else you can help make the new version of Daily Kos the best one ever.