Closed Bug 844967 Opened 12 years ago Closed 12 years ago

Phase 1 Redesign: Pull Hacks blog into MDN

Categories

(developer.mozilla.org Graveyard :: Design, defect)

Product:
developer.mozilla.org Graveyard
Component:
Design
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: Habber, Unassigned)

Details

(Whiteboard: [specification][type:feature])

What problems would this solve? =============================== This allows us to have a voice directly integrated in MDN. Though a single-direction communication channel, it is easier to access than IRC and mailing lists for most users. It also makes the blog more accessible and provides a channel for us to communicate to the MDN community. A possible secondary benefit is that it allows us to create a few "Read-me" style posts to link to for new MDN users before we have redesigned our onboarding flow. Who would use this? =================== 1. Hacks blog readers. 2. MDN community. (1 & 2 can be one in the same) 3. Users that are new to MDN. What would users see? ===================== Users would see a link to Hacks Blog in the main navigation of MDN. Ultimately, the Hacks Blog will take on a consistent style, look, and feel to the MDN site. What would users do? What would happen as a result? =================================================== MDN users that are not aware of the Hacks blog will be introduced to it and get a better sense of what is going on in the community. Besides seeing updated documentation and demos on the site, the users will have another way to see how active our community is. Is there anything else we should know? ====================================== I think there was mention of an upcoming Hacks Blog redesign. I need to investigate how far this is along and also confirm that there are no unknown issues with unifying MDN and the Hacks Blog. We can have the permanent Hacks Blog location be within MDN or simply pull in the post content.
Component: General → Design / user experience
Discussion needed with MDN team to determine how to handle Hacks Blog integration. If wireframes are necessary to communicate our solutions here, I will provide them. Solution will also be based on any Hacks Blog redesign progress & discussions thus far.
Blocks: 844971
Sounds great, Holly. I am going to pull this into our "Design" phase so that we can start working on some concrete mockup/design proposals. Two quick questions: * From reading comment 0, it sounds like this only involved adding a link to Hacks in our navigation. Is this correct? * Would you say the Hacks redesign needs to be done before this?
John, I don't know if any progress has been made yet on the Hacks redesign. I would like to know that and what plans are in place for the redesign. We also need to have a discussion with those involved in the Hacks redesign to determine how to handle how we pull the blog content into MDN. Do we just pull in the posts and style it ourselves to match MDN while the Hacks blog continues to live elsewhere separately or do we start a joint effort right now to have only one location for the Hacks blog within MDN? I believe we have a Hacks blog meeting coming up, which will be a good opportunity to discuss the idea of the Hacks blog existing on MDN.
All great questions. I do not know the answers to any of these questions yet, but I am sure we will talk about it in the meeting. For now, I have copied Rob Nyman for his thoughts.
At MWC, so it'll be a fairly short reply for the moment: I believe the Hacks blog, and Mozilla as a whole, has a lot to gain from it being two different entities. I think the branding needs to be similar, but not the same. - Living in MDN: I think the Hacks blog - as outlined in its guidelines (https://wiki.mozilla.org/Engagement/Developer_Engagement/Hacks_blog) - is meant to be a stand-alone part to raise developer interest and be technology- and web browser agnostic. I believe that being a part of MDN wouldn't help that. And looking at the future, there is a possibility that MDN might turn into a stronger focus on documenting Mozilla projects such as Firefox OS, Apps and more, while Hacks needs to stay independent. - Pulling in posts: I'd highly recommend not doing this automatically. Having cross-posting is confusing for the user, for SEO, for comments and for updating the content (ending up in possible discrepancies etc). In short: MDN is about Developer documentation. Mozilla Hacks is about Developer Engagement. They should complement each other and the Hacks blog is more than happy to point to MDN content. But it's not a part of MDN, in that sense. I'm happy if MDN want to feature or highlight the Hacks blog in any way, but that's about as far as I think it should go. With the redesign, nothing has really been discussed yet and hopefully we'll have a meeting soon to discuss it.
Thanks for the quick feedback, Robert. It will be very helpful to meet in person with you and the MDN team to clear up how we position MDN and the Hacks blog. I thought that while MDN has documentation it also exists to engage developers in the community and be more than just a voice from Mozilla. How MDN positions itself (as compared to Hacks blog, DevHub, Web Platform, Mozilla, etc) is a larger conversation that we definitely need to have clarified before getting too deep into our redesign. "And looking at the future, there is a possibility that MDN might turn into a stronger focus on documenting Mozilla projects such as Firefox OS, Apps and more, while Hacks needs to stay independent." I didn't realize that this was a possibility for MDN besides hosting the documentation since we have DevHub, but we are also working with people from that team to make sure we have our goals differentiated from one-another and collaborate where necessary. We'll be sure to involve you in any further conversation about this.
> How MDN positions itself (as compared > to Hacks blog, DevHub, Web Platform, Mozilla, etc) is a larger conversation > that we definitely need to have clarified before getting too deep into our > redesign. Indeed. > "And looking at the future, there is a possibility that MDN might turn into > a stronger focus on documenting Mozilla projects such as Firefox OS, Apps > and more, while Hacks needs to stay independent." > > I didn't realize that this was a possibility for MDN besides hosting the > documentation since we have DevHub, but we are also working with people from > that team to make sure we have our goals differentiated from one-another and > collaborate where necessary. It's… complicated. :-) Probably part of a bigger discussion, but probably also a good reason for keeping them separate at the time.
> And looking at the future, there is a possibility that > MDN might turn into a stronger focus on documenting Mozilla projects such as > Firefox OS, Apps and more, while Hacks needs to stay independent. This was mentioned at the Santa Cruz offsite, half-joking. We have thought about it, but I am not aware of any concrete plans to do this in the near future. > - Pulling in posts: > I'd highly recommend not doing this automatically. Having cross-posting is > confusing for the user, for SEO, for comments and for updating the content > (ending up in possible discrepancies etc). On the other hand, there is already some overlap between MDN and Hacks. Take for instance the two articles below. They are almost identical. But because this same content is published in two different places, when one changes the other is immediately out of date. One is localized, one is not. One comes with commentary from the community, one does not. For a user to get the most out of what is essentially the same content, he needs to find it twice. https://hacks.mozilla.org/2012/04/taking-pictures-with-the-camera-api-part-of-webapi/ https://developer.mozilla.org/en-US/docs/DOM/Using_the_Camera_API On the relationship between Hacks and MDN, what if we followed the precedent set by the Demo Studio? It is a truly separate site (different features, different management, different goals), but it is listed in the main MDN navigation and has similar branding. https://developer.mozilla.org/en-US/demos/
Of note, Sheppy just mentioned to me that he has a "list of blog posts to integrate into MDN content" and that it's unfortunate that these blogs posts are not written on MDN directly. This underscores my point in comment 8 about nearly-duplicate content living in two places, with two separate sets of benefits provided by each. I understand Hacks has a slightly different purpose and audience than MDN documentation, so perhaps a more careful balance is needed.
> This was mentioned at the Santa Cruz offsite, half-joking. We have thought > about it, but I am not aware of any concrete plans to do this in the near > future. Yep, but I don't think that should be ruled out. Depends a bit on WebPlatform Docs and how that plays out as well. > On the other hand, there is already some overlap between MDN and Hacks. Take > for instance the two articles below. They are almost identical. But because > this same content is published in two different places, when one changes the > other is immediately out of date. One is localized, one is not. One comes > with commentary from the community, one does not. For a user to get the most > out of what is essentially the same content, he needs to find it twice. > > https://hacks.mozilla.org/2012/04/taking-pictures-with-the-camera-api-part- > of-webapi/ > https://developer.mozilla.org/en-US/docs/DOM/Using_the_Camera_API This is where I wrote an article, and then moved it into MDN as a stub/starting point for writing more detailed documentation. > On the relationship between Hacks and MDN, what if we followed the precedent > set by the Demo Studio? It is a truly separate site (different features, > different management, different goals), but it is listed in the main MDN > navigation and has similar branding. > > https://developer.mozilla.org/en-US/demos/ Yes, I think that sounds like the best solution. There's a relationship and it's the same family, but different things.
(In reply to John Karahalis [:openjck] from comment #9) > Of note, Sheppy just mentioned to me that he has a "list of blog posts to > integrate into MDN content" and that it's unfortunate that these blogs posts > are not written on MDN directly. This underscores my point in comment 8 > about nearly-duplicate content living in two places, with two separate sets > of benefits provided by each. > > I understand Hacks has a slightly different purpose and audience than MDN > documentation, so perhaps a more careful balance is needed. The way I see Hacks and blog posts is that it's a way to have a (fairly) short write-up on a technology to get people excited and try it out/learn about it. It's not meant as a documentation, but could potentially fulfill all the needs of the reader. Documentation, in my mind, is more complete and covers more ground. I think basing new documentation on Hacks articles is good, but that that documentation should then encompass more areas and be more general. Also, in all honesty: the Hacks blog has gotten a good amount of attention recently, and by having things in there, it gets seen and gets good coverage. Having a Hacks blog post that would just - more or less - point to MDN documentation would lead to a lot of people not following the links (my experience and stats have shown that so-called links post are not performing particularly well). I'm personally quite happy with the current level and contents of the blog posts on Hacks, and hope that it will be a good starting ground for building documentation from, and take it to the next level. Then, in a perfect world, I'd have the blog post planned out one month in advance, but given lots of external contributors, development progress and much more, I'm happy if I can plan them the week before. :-)
(In reply to Robert Nyman from comment #11) > (In reply to John Karahalis [:openjck] from comment #9) > > Of note, Sheppy just mentioned to me that he has a "list of blog posts to > > integrate into MDN content" and that it's unfortunate that these blogs posts > > are not written on MDN directly. This underscores my point in comment 8 > > about nearly-duplicate content living in two places, with two separate sets > > of benefits provided by each. > > > > I understand Hacks has a slightly different purpose and audience than MDN > > documentation, so perhaps a more careful balance is needed. > > The way I see Hacks and blog posts is that it's a way to have a (fairly) > short write-up on a technology to get people excited and try it out/learn > about it. It's not meant as a documentation, but could potentially fulfill > all the needs of the reader. > > Documentation, in my mind, is more complete and covers more ground. I think > basing new documentation on Hacks articles is good, but that that > documentation should then encompass more areas and be more general. Yes, that's all true; however, it's also true that the people writing these blog posts could write a blog post then spend a few more minutes, spiff it up a tad, and stuff it into the appropriate place on MDN. It's very frustrating having all these experts blogging and not helping with docs. Actually, more than that is the problem of people blogging, knowing perfectly well that there's a docs gap, and not mentioning it to the writing team. :D
(In reply to Eric Shepherd [:sheppy] from comment #12) > Yes, that's all true; however, it's also true that the people writing these > blog posts could write a blog post then spend a few more minutes, spiff it > up a tad, and stuff it into the appropriate place on MDN. It's very > frustrating having all these experts blogging and not helping with docs. I agree that having authors copy their documentation to MDN would be wonderful, but I suspect that it would work temporarily at best. Think Hacks Weekly and #de-status. If a person doesn't enjoy the activity, asking them to do it anyway can only go so far. What if we made this process more automatic? Two ideas that come to mind: Show Hacks articles in search results and automatically add inline links to Hacks from MDN articles. Example of the latter: http://jsfiddle.net/qkL65/embedded/result/
(In reply to Eric Shepherd [:sheppy] from comment #12) > Yes, that's all true; however, it's also true that the people writing these > blog posts could write a blog post then spend a few more minutes, spiff it > up a tad, and stuff it into the appropriate place on MDN. It's very > frustrating having all these experts blogging and not helping with docs. Well, two things. One is that many authors aren't part of Mozilla (and those who are come from other teams) so right now I'm really pushing a lot of people to write articles for free (as opposed to any other paying blog) just because they like Mozilla and I've established that relation with them. Asking them to take that extra time for MDN would be hard. With copying, I think John is right in comment 13, that it would work temporarily at best. It would definitely be interesting to look into what kind of automatic processes we can have here (like generating pages from certain categories on Hacks). Link results in search could wok as well, but I do agree we need separate pages on MDN for many technologies. > Actually, more than that is the problem of people blogging, knowing > perfectly well that there's a docs gap, and not mentioning it to the writing > team. :D The calendar for planned blog posts on Hacks is open - a calendar in Zimbra - and I'd be more than happy to share it. And when it comes to knowing about internal resource gaps, and not having room enough to fix them, well… That's a long list of things then. :-)
Another idea might work something like this: Add a way to Hacks to vote on articles, so that readers can indicate what they think of them. Articles that meet some kind of threshold of upvotes get a bug files automatically suggesting that they be reviewed for inclusion in MDN, with the URL to the post included in the bug. This would let us know about articles people find particularly useful without a lot of manual tracking, and the writers can integrate them at an appropriate time, as time allows.
I like that idea! Definitely something to consider for the Hacks redesign!
(In reply to Eric Shepherd [:sheppy] from comment #15) > Another idea might work something like this: > > Add a way to Hacks to vote on articles, so that readers can indicate what > they think of them. Articles that meet some kind of threshold of upvotes get > a bug files automatically suggesting that they be reviewed for inclusion in > MDN, with the URL to the post included in the bug. > > This would let us know about articles people find particularly useful > without a lot of manual tracking, and the writers can integrate them at an > appropriate time, as time allows. We can do something similar now using Google Analytics -- the articles that are most visited probably most need corresponding documentation.
(In reply to John Karahalis [:openjck] from comment #17) > We can do something similar now using Google Analytics -- the articles that > are most visited probably most need corresponding documentation. Good point, although we need a way to expose that information more easily. That needs to be exposed to the public so they know what they should look at porting over.
Some points from the meeting today: * Hacks should really stay on Wordpress. Building it into Kuma could be interesting, but is extremely unlikely to be worth the effort. * Hacks should continue to have its own domain. * This work is largely blocked by the MDN redesign and discussions about potentially reorganizing or consolidating other developer resources. What we learn in this work will affect our decision on how we pull Hacks in.
Something to note about comment 19... I am fine with Hacks having its own domain. To me, the most important thing at the end of the day is that the sites are related visually and navigationally. That said, we might want to be consistent here. If Hacks has its own domain, Demo Studio should probably have its own domain as well.
Having manually relate the content is not a way to go. Semantic web and RDF come to mind, specifically SIOC. SIOC information http://sioc-project.org/ Linked data information http://linkeddata.org/faq Mozilla Hacks being on wordpress has SIOC/RDF solution http://sioc-project.org/wordpress/ http://wordpress.org/extend/plugins/lh-rdf/ Kuma python based has http://sioc-project.org/specgen There is also general firefox add-on for rdf https://addons.mozilla.org/en-US/firefox/addon/semantic-radar/ Open Calais by Thomson Reuters is also interesting technology that could be utilized http://www.opencalais.com/about
There is a lot of valuable discussion in this bug. However, I am going to close it since the MDN redesign goals have changed a bit. I don't want anyone being confused with the out-dated problem statement or goals that are being proposed here. We will create a new UX bug in the future for this if necessary.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
No longer blocks: 844971
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.