Posterous theme by Cory Watilo

GNOME OPW Internship Wrap-Up

My internship with the GNOME Outreach Program for Women is drawing to a close, and I'd like to take this opportunity to update everyone on my progress with my most recent project, the documentation for System Monitor. In the past couple months, I have assembled the index (which happens nearly automatically with Mallard), and written content for about 18 pages. I am trying to complete the outline submitted by Phil Bull before version 3.2 is released, although I'm uncertain what date this will be for System Monitor specifically. Mike Hill has also submitted awesome pages for this project. Once again, the project is available at Gitorious.

I will certainly continue to contribute once my internship ends. This community has endeared itself to me and I am honored to have been accepted into it with open arms. I'd like to thank Marina Zhurakhinskaya, Shaun McCance, Phil Bull, Jim Campbell, and the rest of the documentation team for their invaluable assistance. I'd also like to mention Julita Inca and Tiffany Antopolski; it was lovely to meet you at Open Help and I hope we can stay in touch.

 

Loss and the Persistence of Content

I usually avoid using this blog for personal stuff, but I'd like to write about something that occurred recently. I had a death in the family. This is not the first time, but it is certainly the first time I've been able to face it with the maturity of an "adult" (whatever that is), and the first in memory of the generation above me rather than two above. It was the first time I realized the impact that this had on the people in the lives of those closest. As a child, the focus always seemed to be on the person who had passed: How did it happen? What is death like? What does "rest in peace" really mean? and on and on. Inherent in this is an element of selfishness, but also ushers in a feeling of helplessness in the face of finality.

It is now that I've realized; funerals, viewings, and other trappings of the burial are really about the people who remain. Rather than feeling helpless, I really do have a role in this. That role is to support and comfort the bereaved; to allow them to grieve in whatever way they want to, and feel comfortable in expressing their emotions to me. In this way, my own grief finds a touchstone, and is grounded in another person rather than the cold skepticism and anxiety I usually rely on.

I recently attended Ignite Las Vegas, an event with a series of "mini-talks" about a wide range of subjects from entrepreneurship to ramen. My favorite of these was Joshua Ellis's Augmenting Reality with Digital Ghosts. He talked about the digital lives that remain after one of us digital content creators passes. One vivid example was location-tagged content like tweets. Our fleeting comments about emotions, experiences, and opinions may not matter to complete strangers (in fact, this is one of the main criticisms of services like Twitter) but no matter their intended audience they persist in a way that will likely result in a different sort of comfort for the grieving.

The person in my family who passed did not have a Facebook page, did not tweet, did not participate in social media in a way that will augment reality the way Ellis spoke of. The only genuine online trace of her memory (that I could find) was an online guestbook at legacy.com. This page is clearly product of 2011 web design. It feels like a strange but well-intentioned attempt to cross the divide. I could certainly wax analytical about the "start-uppy-ness" of legacy.com (they also own gadzoo.com, a community for pet classifieds and news) or the strange peripheral links websites have accumulated over the years, from "print this page" to "share on Facebook." 

Once again, though, if I take a step back and look at the content, it is filled with hearfelt memories and condolences for the benefit of the bereaved. I am struck how little these sentiments have changed. The medium is not the message. Whether expressed through simple attendance at a funeral, spoken condolences, a mailed card, a Facebook post, or flowers at a burial site, people care about those who have been lost and those who sustain the loss. 

It is revelations like these that give me pause when I see sensationalist media proclaim that the digital generation is isolated, socially crippled, and doomed to be forever alone. When someone close to us is lost, we, the masters of the symbolic, are able to provide support and condolences in our own way. We can add to the persistent reality of the Internet by creating content. If there is one certainty of the digital age, it is that content will persist. Content which has made it into the digital archive, from the Gutenberg Bible to Usenet to Facebook status updates, will be passed on from medium to medium as long as technology is able.

We, the producers of software, websites, mobile apps, and more are also creating the "ceremony" surrounding content. We are the funeral mass, the wedding aisle, the VHS tape of a child's first steps. We do the best we can to make the content easy to use, understand, and share. Beneath it all, however, is the knowledge that the content will not remain in our hands for long. Our perfectly crafted desktop UI will become irrelevant in the face of ubiquitous touch-screen tablets, and on and on. We carry the expressions and communications the user hands to us, but we should be ready to hand it off should the time comes.

 

The last slide in Ellis's talk reads: Everything changes; nothing is truly lost.

I couldn't have said it better myself.

 

Workflow (and lack thereof)

First, I'd like to apologize for not keeping up on this blog the past few weeks; I've had some personal issues come up, and it got a bit hectic for awhile. Rest assured, I have been trying to get some docs out in the meantime.

 

One thing I learned about recently was the concept of a "workflow" - a flow-chart like list of steps that comprise a given task. Here is my workflow for submitting documentation for gnome-system-monitor using git.

1. update git repository (git pull --rebase)

         This downloads updates to the gitorious repository which contains the docs.

2. review changes, if any

         If anyone besides me has made changes, here I take a look at them.

3. determine next page to write

        I next look through the stubs written by Phil Bull; he has written a framework for the new System Monitor docs which I'm working to flesh out.

4. open stub, look for comments by Phil

       In each of these stubs, Phil has suggested contents for the given task.

5. open system monitor, find feature

      I would bring up System Monitor, find the given feature, and run through the task if the page is task-oriented.

6. determine necessary format (explanation/references vs step-by-step)

      Some pages require step-by-step instructions, some are a basic review of concepts, and some are a quick reference. Each requires different formatting choices.

7. write it

      Trying to stick to style, and making sure to consult with outside sources (Wikipedia, the application manual, etc.), I write up the page.

8. proofread, follow steps if relevant, revise

    I do basic proofreading, both of the plain text and of the Mallard markup. This also includes making sure that yelp validates the code. If there are steps to follow, I follow them myself to ensure that they are accurate and make sense. 

9. change status to "review"

    Each of these pages has a status indicated by a tag in the code. After writing a draft, I change the date the page was updated and the status to "review".

10. commit and push to git

    This step "commits" the changes I have made in the page files to my local branch, or copy, of the repository. I "push" these changes to the remote repository, meaning a secure upload which makes sure that version-control is taken care of.

11. post to gnome-doc-list

    Lastly, I create a patch of my changes, which are exactly the changes I have pushed to the repository. I submit this patch as plain text to our mailing list, gnome-doc-list@gnome.org.

 

Hope this gives you a clearer idea of what I'm doing! I realize I fail to communicate details sometimes. I welcome your comments though, they serve to keep me on the right track.

 

Back on track, perhaps? (Of System Monitor, Mallard, and regret.)

Alright, I know when to admit defeat. If a project requires me to spend hours pulling my hair out only to restart it every 24 hours, and to learn new skills I only have beginner experience in, perhaps it's not tenable as a short-term, summer internship project. (not that I won't continue hacking it in the background...how could I not!)

Instead, I've picked up a docs project we outlined at the Open Help hackfest: GNOME System Monitor.

 

Screenshot-system_monitor
(Yes, I know it's not the default Adwaita theme, I just love theming too much. It is my downfall. At least I changed the logo back into the GNOME foot from the Arch Linux arch... ;) )

I haven't gone too far into what I was doing previously with the Documentation Team. The project we started out with was writing docs for, and revising, Desktop Help. The application in GNOME that views these help files is called Yelp. Yelp looks like this (if you are a cool themer like me):

 

Screenshot-desktop_help
The markup code that takes unorganized, confused raw text, dresses it up, makes it look presentable and tells it how to get to the store is called Mallard, designed by the inestimable Shaun McCance (my mentor for this project). I realize that I should have explained all this to you long ago, but the Open Help conference left me full of new ideas that were, like most of my new ideas, beyond my scope. Because of this, I started reaching and jumping to get the shiny mobile apps off the shelf, trampling over all the other awesome toys I understood already. In any case, sorry toys. I'll try not to do it again. So. That index page I just posted for desktop help? The code looks like this:

 

Screenshot-index
Now, the first thing that struck me about this code was: "Oh my god, it's full of tags!" There is very little plain text. From the Yelp output, it seems like there should be much more. Well, Mallard is smarter than that. All those links? They don't just link. They grab the content from the pages they link to, figure out which part to use, and display in in a convenient, highly configurable form. Oh by the way...most of those tags? They are taking care of the fancy mouseover business at the top. The screenshot in the top table changes on mouseover of the links on the right. The rest of the content is pretty much in this tag right hurr:

 

<links type="topic" style="toronto" groups="

       web media files

       net prefs hardware

       a11y tips more-help"/>

That's it. Really. It knoooowwwws. Each of those groups (web, media, etc.) holds another magical page full of awesome ducky tags. It all fits together seamlessly, and when you get down to an actual content page:

 

Screenshot-desktop_help-1
the content writer can pick up a framework page for a topic (called a stub) and get writing without worrying too much about organization. Neat, huh? (Those fancy links at the top? I'm going to write about them next time. Next time. Seriously. Make me.)

Anyway, Desktop Help, being in a much more complete state, even more completed and updated after our hackfest, I found a bit intimidating to contribute to at this point. I got out my trusty Gitorious account, scored an invite to the gnome-documentation team, and got to work writing pages for the System Monitor docs (stubbed out by the equally inestimable Phil Bull, rogue astrophysicist). I've already written a couple pages on exciting topics like CPU capacity and command-line alternatives to system monitor tasks! So yeah, I'm gonna get back to working on what I can do well, and leave my little duckling for a rainy day. As much as I would like my brain to be a multi-core processor...pretending that it is is just a crash waiting to happen.

Why GNOME mobile help?

In my previous post, I got a pretty pointed comment that actually helped me clearly state my goals for my project. I'm going to paste my reply here because I think it's useful to draw my roadmap for you all:

The idea is not to make GNOME help specifically for the phone. GNOME help is generic content for me to work with. My ultimate goal is to create a tool like yelp-build to translate *any* Mallard-formatted documentation into a mobile format. One possible use I can think of for this specific project, however, is a mobile equivalent to a physical manual. One can hold the manual in their hand while using their desktop or laptop, following directions in the help.

More broadly, this will be useful in the short-term for GNOME projects that already have Mallard-formatted help and may in the future transfer to a mobile format (games, music players, chat programs, etc). In the long term, as new GNOME apps specifically made for a touch screen are produced, this could be a counterpart to Yelp in that medium.

Behind each of the bare-bones one-screen UIs was a pretty intense analysis of content and structure, as well as some time to familiarize or re-familiarize myself with the structure and code needed. They represent two major projects: 

* The first (duckling) is mobile app written in Java with an XML UI specifically for Android that will run as a standalone port of Yelp. 

* The second (gnome-help-mobile) is a mobile website written with HTML, CSS, and Javascript, Along with it is the tool that takes .page files written in Mallard and translates them to the completed mobile site.

The first of these two is on the back burner, but I will return to it. It is easier and more relevant to produce the second right now.

Since moving content and applications into a touch-screen environment is vital to staying relevant, I believe it is important to start building the infrastructure for a documentation system commensurate with this movement.

Hope that clears some things up, keep the constructive criticism coming! :)

 

quick update on GNOME help mobile

I don't really have the motivation for verbosity right now, so I'll just give you a nice list:

 

  • Switching gears from an actual mobile app (duckling is on the back burner) to a mobile website. Ideally, I'll make a version of the yelp-build tool to translate into this new format from mallard.
  • Site progress is on github: https://github.com/polymathica/gnome-help-mobile lots of little frequent updates, sorry. Also my code is in disarray right now, don't look.
  • Here's a screenshot of what I have so far: 

If all goes as intended each of those will expand or slide into nice, touch-friendly submenus.

...back to the CSS mines I guess. (or minecraft mines maybe on a break)

Duckling: A Mallard Client for Android

I decided to shift directions for my internship and start working on a content viewer rather than the content itself. I am so excited!

I'm calling it....

Duckling!

 

Clip art in the Public Domain, via Sutrannu

Font is Cantarell by Dave Crossland, under SIL Open Font License

so basically all I've got is a UI sketch and preliminary layout code from DroidDraw:

(this is based on GNOME Desktop Help)

 

UI sketch

le code:

 

Some things I want to think about/do:

  • Github vs Gitorious?
  • Use IntelliJ?
  • Review Android docs: User Interface
  • Run through some of the DroidDraw tutorials
  • Would a Web App be more practical? What are the advantages of a reader from scratch?
  • Which Yelp code is the most vital to port over first?
  • Hey, look it's Friday already. Who wants to go dancing?

Open Help Conference, June 3-5 in Cincinnati, OH

I am back in Vegas after the awesome Open Help conference in Cincinnatti. This was my 1) first time in Cincinnatti 2) first time meeting any GNOME people in person 3) first non-science conference 4) first hackfest. Everything I experienced confirmed my growing conviction: the Open Source community is full of awesome people and I want to be part of it for a long time to come. I thought I'd do a rundown of the talks today and then a review of the hackfest in the next post. http://www.slideshare.net/event/open-help-conference-2011 is a nice SlideShare page for the event. SlideShare is a new tool for me, but it allows you to submit and share your presentation slides and notes for an event collaboratively.

The first talk was by Anne Gentle, entitled “Sprints and Stacks – Building a Documentation Community”. I think this was a great introductory talk for this conference, as it was the first “Open Help” conference ever (as far as I know). Anne's talk was very comprehensive when it came to establishing, improving and growing a docs community. It made me inspired and excited to be a part of the documentation process for GNOME. Another thing she talked about was documentation sprints, which I believe we refer to as hackfests. :) Either way, the principle is the same. Get your team together, time it right, and work work work! (With the added support of others' physical presence, of course.)

Next up was Dave Robbins of GE with quite a different perspective on docs that I have never stopped to think about. His “Remember the User!” talk grounded in reality some of the nebulous things that a technical writer may not think of when knee-deep in software documentation. One of the most interesting things he described was how he documents a complex industrial machine for a relatively non-techie target audience. These workers do not have much time to learn a new system, and there is a high turnover rate. Things like the inclusion of video and the physical placement of the documentation are factors that certainly vary based on the target audience and the product being documented, and may not apply as much to some software. Considering why they are needed, however, could be quite enlightening.

The third speaker was Dru Lavigne on the process of “Starting an Open Source Certification Program”. This talk was a little more difficult for me to connect with, as I had never even considered the fact that certification was something mere mortals could start. (In my mind, certs are MCSEs, CCNAs, A+...big names from big corporations that would likely have nothing to do with Open Source or Free Software. Then again, I did not know until this conference that Red Hat was so dedicated to Open Source software, and they are HUGE.) Anyway, the one thing that came through loud and clear was: it is very very difficult. It requires quite a bit of money, effort, resources, and time. Some interesting facets of the endeavour are psychometrics, “the science of assessment”, and what it takes to write questions for exams. (No “none of the above”!)

After a delicious lunch, the next talk was by Janet Swisher of Mozilla: “Engaging developers in Mozilla's documentation”. I have used Mozilla's products for years. I started using Netscape Communicator in 1997 or so (mostly to update my Geocities page with animated .gifs of kitties...) and have used and recommended it to others in various forms since then. It was interesting seeing the evolution of the Mozilla team as well as what they are doing today. This was an interesting peek into something I have yet to do with GNOME: communicate with developers about the product being documented. I was surprised at how hands-off some developers seem to be once their software is released into the wild, though the challenge of documenting them is nowhere near insurmountable.

The next talk was by Jennifer Zickerman, also of Mozilla (Thunderbird, the email program). She spoke about “Coordinating Documentation and Support: Turning Complaints into Contributions”. She gave a very good overview of the challenges and requirements in developing a strong Open Source documentation team. One fact about the Thunderbird team that I was amazed by was their user:contributer ratio. They have 10 employees, 50 contributers, and 10,000,000 users (give or take a couple million). One way they deal with this is the “Army of Awesome”: a never-ending feed of Twitter users referencing Mozilla products, with varying levels of praise, animosity, and vulgarity. Aspiring documentarians and support people can easily contribute by dipping into the stream and replying to individual users with advice. It's a great first step towards contribution.

Next up was my GOPW mentor, Shaun McCance. His work with the xml-based markup language Mallard is allowing for a new framework for user help in GNOME to be developed which is more lightweight and flexible than the outdated DocBook. It is topic-oriented and uses conditional processing; the upshot is that you can have a “table of contents” called a “guide page” which keeps itself current as documents are added, edited, and removed. My work in the internship thus far has been about writing in Mallard for GNOME Desktop Help, but I am quite interested in getting involved in plugins or extensions that use it as well as contributing to the official GNOME help app, yelp. In any case, Shaun gave a brief history of Mallard and yelp development (including a bit of insight into the reaction of some GNOME community members on the release of Ubuntu's Unity).

Lastly, Lana Brindley spoke about her work at Red Hat in “Open Source Documentation in Four Easy Steps (and one slightly more difficult one)”. Her talk covered a lot of ground, some of which I'm still catching up with now. One thing she mentioned was DITA, the “Darwin Information Typing Architecture”. It is a data model (kind of a framework) for writing and publishing that is XML based. It is far too complex for me to cover here; however one essential piece of it is the “Concept, Task, Reference” paradigm used in writing docs. This way of looking at things can be applied in writing for GNOME Docs, so I'm looking at it with interest. As her talk continued, I found myself in way over my head (except for the Skynet references) so I'm going to cut it short rather than botch it. The steps mentioned in the title, however, were as follows: 1) Process is king. 2) Get the right tools. 3) Keep it open. 4) Keep it real. 5) Review constantly. Sounds reasonable to me!

The next day of the conference (Sunday) we had some fascinating talks on a huge range of subjects from gamification to recruiting new contributors to the principles, basics, and goals of Open Help. One highlight for me was when Dave Robbins, who was installing Ubuntu on his laptop for the first time as we sat there, asked the room: “Why should I use Open Source?” The room exploded. Everyone has something to say on this topic and has thought about it, written about it, and talked about it for years. As things quieted down, a few key contributors spoke eloquently to the question, bringing in experience, insight, and perspective from all quarters. I hope there is a video of the talk, as I'd like to hear some of the replies again. In the end, Dave announced that he was running Gnome 3 on Ubuntu...and we all cheered. There is nothing quite so encouraging as a real-life example to show you that you aren't shouting against the wind. Next time: Hackfest!!

Oh, and before I forget, I tried to make a list of all books mentioned by speakers at the conference as well as some written by speakers but not mentioned. If I've missed anything vital or relevant, please let me know and I will add it right away.

 

 

GNOME 3! My experiences so far...

To kind of pick up where I left off, I want to start with GNOME today. Since I kind of went overboard with history last time, I'll instead direct you to a few pages where it's summed up much more accurately and completely than I could pull off: 

GNOME's "About Us" page

Wikipedia on GNOME

History up to GNOME 1.4 by co-creator Miguel de Icaza

The GNOME Foundation

(Also, my apologies to less Linux-savvy readers, but I'm going to start writing with assumption of a higher level of technical knowledge, as I believe most of my readers are coming in from GNOME Planet, an aggregator of GNOME-related blogs.)

 The big news with GNOME right now is the official release of GNOME 3.0 happened on April 6, 2011. This UI is slick. Majorly slick. The Activities menu gives you an incredibly quick and intuitive overview of everything you have open, a bookmarks bar, and all your workspaces. Before you realize what happened, you're viewing the window you need on a new workspace and you're ready to go. If you are used to a little more customization, it can be hard to get used to at first. I've found that I have had to change the way I use the computer somewhat to use it efficiently, and train myself to actually work differently. I suppose this is true of any new interface, but it is still a bit of a shock.

See, I told you it was slick. (click to biggify)

For one, I was used to creating a little row of my most commonly used shortcuts on a panel across the edge of a screen. At a glance, I could click the one I wanted without a second thought, eventually getting used to the position of the icon so that I was able to click it without even looking. Now I have the extra gesture of sliding the mouse to the upper corner before I can even see the applications. (I haven't really used the keyboard shortcut) One advantage is that I can see what is already open, as open apps have a highlighted icon. Overall though, my brain has started to process things differently, and I don't think this is necessarily a bad thing when it comes to productivity.

No longer can I glance at all my programs in a moment of distraction, decide to open Chromium, and end up surfing the web for 3 hours on another workspace. I have to deliberately open Activities, and instead of going straight for the browser, I am forced to look at everything I already have open. The moment of distraction has passed, and I'm back on track. Even the notification tray is out of sight, and notifications disappear before you have the chance to get too far off track. The thing about this is, it is kind of frustrating, mostly because I'm lazy. This much productivity must be bad for me somehow. Why has the machine I created turned upon me thus? I, who gave it more RAM than it even deserves, who supplies it with a steady source of electricity...what hubris I had to think that I could possess such power, to contain it in a case of mere sheet metal and plastic...noooo the neurotoxinnn...Ahem. Nothing to see here. Just got distracted for a minute. Anyway, GNOME 3 has mainly been a pleasure to work with. I'd like to play with some of the extensions and user themes at some point.

Join me next time, when I'll talk about the Documentation Program and the Open Help Conference. (I'll try to get this post in before the conference, and I'll definitely be liveblogging (livetweeting? vivo-micro-blogging?) the conference at my twitter here. Feel free to add me, although maybe read back a little and make sure you don't mind all my silliness.