Blog posts by
17 Oct 2014 »
It is my last week at the Ascend Project, and I am moving hard and fast to finish. I received some conflicting advice on the process of contributing to two open source user experience (UX) projects. For the first project, adding the ability for a developer to respond to a user’s review, I sketched my ideas using basic lines, text, and some color-coding.
The feedback from my mentor was to brainstorm using scrappy drawings like this instead:
I resisted the idea because even more than drawing, displaying my handwriting for the world to see causes great fear and trepidation in my heart. Also, I do not have a scanner, and taking pictures would add extra steps. After I mentioned my discomfort with what I called two-dimensional brainstorming, Lukas explained to me that the paper process was a way for people to share ideas without becoming too invested to consider other possibilities. That sounded liberating, and I thought it might also take the pressure off a team that wanted to present options without stratifying collaborators by technical skills or drawing ability. You could literally just throw away your paper sketches.
In the meantime, Jessica recommended this article to me after I was thinking out loud about the open source user experience and the design process within it. The article describes more about prototyping with HTML, which is closer to my personal preference.
So I tried drawing. I found the process frustrating, but I decided to try it again with a “call-to-action” design bug. The response had some good advice, but it also had a new “assigned-to-contributor” tag, which led me to believe I’d lost the bug.
There is some good news even if I “lost” call-to-action bug. I am still working on the Marketplace project, which is great. The mentor responded to me on Bugzilla and is fine with me using what I call line-and-text sketches. He gave me some really straightforward deliverables as well. I plan to leave out most of the color coding and some of the behavior I initially set out to propose because the colors may have been confusing, and we are in a different point of the UX design process than I initially thought.
I am proud to have begun contributing, and I have started to understand a process of user experience engineering beyond the rapid prototyping and product development I’ve been practicing for a few years contributing at hackathons and learning independently. In my opinion, both of these are being mentored as interaction design bugs to resolve as part of improving the user experience. Since both contribution opportunities will help developers building on the open web, I am happy to work on them as a volunteer on a more extended timeline than I had during Ascend’s full-time open source training program. The experience overall gave me a taste of collaborating around user experience within a large organization just as I had hoped for when I applied to the program.
As for the create-an-app bug, I will have to review the documentation again to confirm since I am happy to work on it some more. Until then,
It’s a cliff-hanger, y’all!
10 Oct 2014 »
Hint: Keep Reading
1.Question Closed: Developers, who validate and reject questions and answers on the site using a voting system, had deemed this question invalid.
3.In case you missed it, people have closed this question, and this is why:
4.There was discussion.
5.An attempt to answer.
I don’t even know if this answer is right, but it changed my own approach to the question. Is HTML5 a language? A stack? Right now, I don’t know, but I am looking forward to going down this rabbit hole when I finish this blog post. So I leave you with this:
As a teacher who adores the Socratic method, I value questions as part of the learning process. Wikipedia says that the Socratic method “is a form of inquiry and discussion between individuals, based on asking and answering questions to stimulate critical thinking and to illuminate ideas.”
My inspiration for applying user experience principles to open source development has a lot to do with my passion for questions and their power to solve problems that pervade the technology community. A safe environment for questions is not only more pleasant, but it is a more responsible approach to work.
We all want to get things done. What does it mean that the quest for answers might continue from here? It is heartening to see that members of StackOverflow asserted more useful ideas into the conversation. Perhaps we should start with Jayden Lawson’s words:
“Be constructive, please.”
Such nice manners.
The screen shots in this blog came from this site
01 Oct 2014 »
A tutorial on using your Mac terminal command line to run different versions of Firefox at once
If you decide to test bugs in different versions of Firefox you may want to run more than one version of Firefox at the same time. If you try to open a second Firefox on a Mac out-of-the-box, you will see an error message like this:
Fortunately, one of the first things we did at Ascend was set up our computers to run different versions of Firefox at the same time. Here are the steps:
- Make sure you save these instructions somewhere outside of a Firefox browser.
- Close Firefox.
- Locate the Profile Manager from the Terminal window.
- Double-click to open the terminal and navigate to the binary folder that contains Firefox’s Profile Manager.
In English, that means:
Type or copy and paste the following file path into your command line.
It will look like this but it will have your hard drive’s name instead of 02100, etc.
Follow the instructions in the next few panels.
I named the new profile for this tutorial ’Normal_Firefox’ (without the quotes).
For fun, I copied and pasted the file path to the user-related data notes that I keep.
The rest is up to you. Read everything on the screen and decide which choices are best for you. You’re in charge!
Link to I’m in Charge! [coming soon]
Now, create another profile with a different name and a different version of Forefox. Were you able to make profiles for your different versions of Firefox? If so, go claim your badge!
29 Sep 2014 »
As I started looking for bugs, I decided to lead with two questions:
- What do I want to learn how to do?
- What products do I find interesting?
I also made an extra effort not to simply choose technology that felt familiar as I explored. These are the bugs that caught my attention but did not make the cut. I call them “The Nopes.”
- Bug 996870 The heartbeat check should verify that the db is healthy. https://bugzilla.mozilla.org/show_bug.cgi?id=996870
This bug sounded like a great opportunity to learn about databases and security. I also believe that automation is part of the magic of computing, so if I could run an automated test, I would gain “street cred” for participating in the infamous “Heartbeat” fix. I found the code base pretty easily on GIthub, but then I saw a list of installations that promised to make me miserable. Also, I was confusing “Heartbeat” with “Heartbleed.” But that might be okay since other people have made and/or found ways to address the fact that it is a common error like in this article. Or maybe it is not an error. I will leave this one for the parking lot - I will return to it later… maybe.
This would have been a great opportunity to take part in the just and righteous campaign against captchas, but the last action on the bug was in March 2014, and I was worried that no one really cared anymore. Also, the word “triage” seemed to confirm that idea. https://bugzilla.mozilla.org/show_bug.cgi?id=632204
I want to learn to build an API for my personal data, so i thought this bug would immerse me in how-to-build-an-api world. It also involved code migration, which is quite a marketable skill. It is also a headache for experienced developers so as a first bug, it might not be such a great idea. Not only is there a lot to learn (which is great, actually), but there may be product and process decisions that might hold up the code. Since the Ascend Project is only six weeks long, I decided that I could not make the best contribution at this time. https://bugzilla.mozilla.org/show_bug.cgi?id=1003236
Then I found Sea Monkey.
24 Sep 2014 »
I have known for a long time that I can learn anything. One of my goals in the Ascend Project is to gain more confidence that my code will do what I want it to do.
I started learning Python by breaking things in the command line. For example, to find out if my Python 3 syntax was correct, I would type what I thought I remembered and see if it yielded the result I expected. If I did not get an error message, I raised my arms in the air to whoop up my victory. That was one route towards confidence, but I was not actually finished because I did not always understand why my code worked. I was fine with that until I started learning GitHub. I needed more.
Most people tout the way that GitHub allows a developer to track errors and find your way back to what you did to break your code. Since I am still learning to navigate the terminal and even comprehend help, I find that GitHub forces me to know more before I do anything. It puts a lot of pressure on me to get it right the first time, which complicates my journey to learn by breaking all the things… okay, maybe not all the things, but you know what I mean. I break this less now because I know more, and recovering takes a different set of steps. For example, if I delete two files while I think I am moving them into a new folder, I cannot just reassign a variable or change the syntax (as I do in Python). My changes have more baggage.
My Error: I made changes to my local repository before doing a ‘git pull.’ I was about to overwrite several minutes worth of work. Yikes! Then…
Magic words to the rescue!
Coding is a superpower, and these are magic words that you can use to recover from changes that you have not yet staged or committed in Git.
$ git stash $ git pull folder name repo_branch_name $ git stash pop [Then resume with the normal push process] $ git add . $ git commit -m “Stashed the changes I made to local repo, pulled the newest version of the working branch, added, committed, pushed again.” $git push
To commit the changes that I had rescued, I used pop then the normal push process (git add. , etc.) and followed the pull request process on Github.
There is a caveat to this blog post: As with real life, I have to make mistakes publicly because my inner circle is not always equipped to offer the help I need. If there is anything wrong with these steps, feel free to suggest the changes you believe I need to make.I may push for more information if I need to understand better, but I welcome constructive feedback.
There is more information about this item on this site.
17 Sep 2014 »
Here are the results of my first Mozmill test, which I used to determine what was working and not working in a Firefox Nightly browser:
I used tiny.url to personalize the link and make it easier to read. The link looked like this at first:
This was my first experience with automating anything from the command line. I had an easier time keeping up and completing the process than I’d experienced with GIthub and navigating on a new Mac, but honestly, I do not remember much about running the test. What was most compelling was how amazing it felt to realize that I had brought a browser to life as part of the process.
If I do not get to use Mozmill it during the process of fixing my bug(s), I look forward to revisiting it when I need to reminisce, nerd-out or level up for a testing project. I am confident that I can do it again - even if something in the process changes - which is what matters.
15 Sep 2014 »
This is how I travelled from open source failure to contribution at the Ascend Project. Go libre!
*There is some explicit language in the audio of this link. Sometimes, that’s just art and life.
10 Sep 2014 »
My first day of the Ascend Project reaffirmed that I was about to experience a life-changing opportunity. I would have the time and support to link the loose ends that had characterized three years of informal learning in technology. I expected to dive right into code. That is not what we did.
Instead, we spent time getting to know each other’s strengths, remembering our own contributions, and learning how to nurture a healthy, cooperative learning environment. I never expected to have this kind of experience in technology, but I am grateful.
As an educator, I have had the fulfillment of watching others (mostly children) grow. As a sound artist, I have been fortunate to watch other artists grow in the rich community that I left behind in New York. To think about the challenges that some of my colleagues are overcoming to take on this challenge is overwhelming. I look forward to witnessing what “grow” means to the unspoken superheroes around the table where I type this blog post.