Going into this internship I wasn’t exactly sure what to expect. All of my classmates interned with print-heavy design firms, so I was the first to work at a digital firm. Well, six months have passed, and today is my last day here at SfG. So I thought I would share a little bit about my experience.

I learned a lot of what I hoped to and expected to. I learned small tips for Photoshop, the kind you pick up from working with new people; everyone has their own set of neat tricks and cheats. I learned how to design with both desktop and mobile in mind. This may seem small, but it used to seem like a daunting task to create something that can benefit both devices, and now it’s like second nature. And I learned simple things like how to name and nest your files so you can find everything easily, as well as how to set up your Photoshop files so someone else, probably a developer, won’t want to kill you when they try to navigate your PSD.

However, there’s a lot of stuff I learned that was completely unexpected.

I’m a person, not a number. People have dogs who need to go to the vet, children who get the flu, children who give them the flu, grandmas who need a ride to the doctor. We lock our keys in the car, our babysitters bail, and our grandparents die. I never felt penalized when life got in the way of work here at SfG, and I don’t think anyone else did either.

I don’t need to work somewhere where everyone lives and breathes design. Throughout college that’s where I thought I belonged, but I was so very wrong. That’s not what it’s like here. Here everyone loves what they do, but they have lives outside of work and are passionate about something else in addition to their job. Jamey can talk your face off about space. Erik #1 has chickens. Kevin really likes beer, good beer. Saying Andy loves motorcycles might be an understatement. Kyle longboards like a champ. Shannon has some mad hand-lettering skills. Sara really loves books. Peter has a serious Hawaiian shirt collection. And Brad just really loves Rebecca Black’s Friday.

I also learned some minor but life-changing things in my time here. Joe made me realize why having my own server is something I need in my life. Eric #2 taught me that if something you want doesn’t exist, you should make it. Being the youngest one in the office means half the time you don’t know what anyone is talking about. Being the youngest one in the office also means you have the benefit of making everyone feel old, and who doesn’t love free entertainment? Ryan taught me, and Joe confirmed, that developers love it when you design with them in mind. And Kevin taught me that it’s okay to ask questions about things I don’t understand (which is basically everything they do). And Sara inspired me to go back to school for development.

So, I now have a basic understanding of Ruby as well as Rails, but there’s still room for learning. I’ve become incredibly familiar with GitHub, but I don’t like the Octocat. And I’m wrapping up season two of Game of Thrones; I want to be Daenerys’ best friend and Joffrey can suck it. However, my lack of love for Top Gear has not changed, I’ll probably never own a motorcycle, and I like my one-speed cruiser bike. I am, however, currently shopping for the perfect wicker basket to go on the front.

I don’t know what’s next; but going back to school for web development has been tossed around a lot. If you wanna keep up with me as I leave the intern nest, you can find me on Twitter and Instagram as @iamlizlewis, or shoot me an email at iamlizlewis@gmail.com.

The post Thoughts from a Design Intern in a Development Firm appeared first on Software for Good.

Jamey suggested we take a different approach—get rid of the corporate t-shirt feel, and make something that was less ‘company t-shirt I have and never wear’ and more ‘t-shirt I’d actually buy’. With the freedom to letter something awesome, not constrained by branding, I started some quick pencil sketches. We’d decided on a lettering-only vintage/sports inspired approach.

From the initial pencil sketches, we narrowed down the field to a few iterations. These were turned into tight pencil comps, which were eventually inked to better reveal the letterforms and layout.

This led to the selection of the final design. You may notice that the final selection was not an original sketch. I ended up combining the aspects of each design we liked best and created a happy medium between the two.

It would have been possible to stop at this point, scan in the final design, clean it up in photoshop a bit and send that to the printer. However, there were a few rough patches here and there and in general the lettering needed some adjustments, so I moved into vectorizing the design.

This was done in Illustrator, with the final inked design as a guide. Usually, I’ll start from scratch when tracing lettering, but I wanted to preserve some of the quirky not-quite-right aspects of the lettering—some of the ‘wonkiness’ if you will. So, I started from a live-traced vector and cleaned the piece up by hand.

In this screen capture, ‘Software’ is partially cleaned up and adjusted, whereas ‘for Good’ still needs some adjusting.

Once the lettering was completely vectorized, we sent the final off to the printer.

The result was a t-shirt that we were stoked to wear, and that other people were excited about, too. We ended up reprinting an additional run with three new t-shirt colors added for friends and family that wanted a piece of the action.

Interested in a shirt? Drop us a line at info@softwareforgood.com and we’ll see what we can do.

The post Soft-wear for Good appeared first on Software for Good.

An intro to a programming language usually starts off with the traditional “Hello, World!” program. So, in honor of that, I would like to say:

    puts "Hello, World... Cup!"

Today, we’ll be looking into a few tools to help you transform your computer desktop into a World Cup scoreboard. The main tool is the API that my coworker Eric wrote. It’s received a ton of traffic throughout the tournament. At about 15 million API calls, it’s had a lot of traction throughout the community, and it’s what we’ll be using to get the scores on our desktop.

Here is what the final screen can look like:

Let’s get started.

The first thing you will need is a Ruby installation. Ruby’s bundled with OS X, but if you’re on Windows, you’ll probably need to install it.

Next, you will need to install a tool called GeekTool. This is a fantastic tool for making your desktop your own, and it will be an integral one for getting your scoreboard up and running.

Once you have those two things installed, you’re ready to get to work. I suggest creating a directory to store all of your Geeklets in one place. I’ve named this directory Geeklets.

Let’s change to that directory using the terminal:

    $ cd ~/Geeklets

Let’s add the base of our scoreboard now. Start up GeekTool and you’ll see something like this:

I created a special group for my World Cup Scoreboard. Feel free to do the same.

Our Geeklet is going to be be dynamic, so we’ll need to use the shell Geeklet. Drag that on the screen like so:

Here, be sure to change the refresh time under the command field. The API updates every minute, so 60s should be a good amount. This tells the Geeklet to run the script every minute to keep it updated.

The next thing we need to do is create a script that GeekTool will use to run our Ruby code. The Ruby code will, in turn, call the APIs at worldcup.sfg.io and return the data to our Geeklet. To do this, create a new text file using your favorite text editor. Be sure to save this in your Geeklets directory as world_cup.rb

Don’t forget to make the Ruby file executable with:

$ chmod a+x ~/Geeklets/world_cup.rb

In your terminal enter in the line:

$ gem install httparty

This gem is what we’ll use to get data from the worldcup.sfg.io website. If you’re using RVM, make sure you install this in the system ruby.

In the world_cup.rb file add these lines:

    #!/usr/bin/env ruby

    require 'json'
    require 'httparty'

In the scoreboard Geeklet’s settings, make sure the command is set to:

    ~/Geeklets/world_cup.rb

Let’s get to the heavy lifting. I’ll post the full code and then explain it after.

#!/usr/bin/env ruby

require 'json'
require 'httparty'

BASE_URL = "http://worldcup.sfg.io/"

def get_json(url)
  response = HTTParty.get(url)
  json = JSON.parse(response.body)

  return json
end

def prepare_matches(matches)
  matches.each do |match|
    home_team = match["home_team"]
    away_team = match["away_team"]

    format_board(home_team, away_team)
  end
end

def format_board(home, away)
  print "#{away["code"]}" + " " * 19 + "#{home["code"]}"
  print "\n" * 2
  print "#{away["goals"]}  -  #{home["goals"]}"
  print "\n" * 2
end

def today
  url = "#{BASE_URL}matches/today"
  matches = get_json(url)

  if matches.count == 0
    puts "No matches today"
  else
    prepare_matches(matches)
  end
end

today

First, we set the BASE_URL as a constant so that we don’t have to type out the full URL every time we need to use it.

In the today method we first set the url that HTTParty will use to get the match data. Then we use the method get_json(url) to get the list of matches that are occurring today. Then, in line 35, we check to see if there were any matches in our list for today. If not, we display a message in the Geeklet letting us know. Otherwise, we use the method prepare_matches(matches) to format the matches into a scoreboard like format.

The format_board method uses each team’s country code, and then adds a little bit of spacing to make the output shown in the geeklet look nice.

The only thing left is to add a title or a logo to the scoreboard. For a title, you can add another shell geeklet and use the echo command directly in the command field of the geeklet like so:

echo 'World Cup'

Joe here at Software for Good gave me the idea to use an Image geeklet with the official World Cup logo.

Here is our final product:

That’s it! It’s pretty simple, but it can add a little fun to your day. If you’d like to read more about the World Cup API and how it started, head here. There is a lot of data out there, so take this little Ruby script and play with it. Add your own methods and see what you can do. I enjoyed writing this script, and I’m enjoying learning about the World Cup as it continues.

The post Hello, World… Cup appeared first on Software for Good.

TeX (pronounced ‘tech’ due to some Greek letter shenanigans), is a programming language created by Donald Knuth. A programming language! Typographers and designers be like ‘whaaat, no thank you,’ but before you run away, read up a bit on the history of the language. Knuth created it to solve a design and typography problem. Basically, his seminal book The Art of Computer Programming was up for a refresh, and the proofs he received turned out to be crap. He said, ‘I can do better’ and set about making TeX happen.

The history of this programming language intertwines with the history of typography and layout, but it just didn’t catch on for the average typesetter. TeX is largely used now in academic circles, especially for mathematics and sciences, but it’s a pretty powerful (and free!) typesetting tool. Because it was built for typesetting specifically, TeX feels like the proper tool for words from the start. TeX, though a programming language, actually belongs on the timeline of the history of printing.

Some basic aspects that might pique interest:

• Documents are very easily be compiled into pdfs.
• LaTeX is a system built on the TeX language that allows for more complete control over formatting.
• XeTeX is a typesetting engine that allows for even more typographic needs such as opentype, font control, unicode, and other fun type stuff like alternates.
• Typographically, you can do a lot with TeX + friends
• Because TeX is text-based (not WYSIWYG), you can hook it up to version control like Git.
• It’s all FREE and the documents can be opened/compiled/read by anyone (just need to download a little packet).
• Documentation is not great. Because TeX was created back in the day, a lot of websites and tutorials are hard to sift through. They are either full pdfs or they specifically address using math/tables, which are things you might not need on a normal basis.
• However, you can pretty much Google any problem you come up on, and it’s all well worth the learning.

Dropping in controls for kerning, ligatures, and leading are all quite simple and similar once you get the knack for it. Formatting requires some of the same type of abstraction required of a web designer when creating a layout (the ability to visualize a result beforehand) and the sensibilities of a print designer (basic typography rules for print). It’s a great tool for the dev who occasionally needs to create a document for print (look up using SublimeText + Slim with TeX) and a great tool for print designers who are dipping their toes into designing with code, or for the designer and client that need to share edits easily but don’t necessarily share the same editing programs. Keep in mind that not every document should be a TeX document. Using the right tool for the right job is a huge part of designing (and life), but familiarizing yourself with a tool like TeX is well worth it.

Some reference for getting started:

TeX User Group

LaTeX tutorial

Wiki Book for LaTeX

TeX Stack Exchange, a forum for questions and answers

The post TeX + Typography = TeXcellent appeared first on Software for Good.

Good typefaces for coding all share a few key aspects (and more). One classic aspect is that typefaces designed for coding are monospaced. Monospaced means that each character takes up exactly the same amount of horizontal space. So, a lowercase m has to occupy the same width as a lowercase i. This provides perfectly vertically aligned glyphs and spacing, which is great for coding since alignment is helpful for scanning information and grouping things. Another key element is that certain characters need to be well distinguished from one another. The capital O can’t look like a 0, the lowercase l needs to be distinguished from a 1 and an I.

People who stare at code all day likely need the code optimized for readability at small sizes, so often the best coding typefaces will have larger x-heights. This allows lowercase letters to appear a bit larger than a more traditional typeface, which makes the characters easier to identify when small. There’s a bunch of other stuff, but that’s like a whole other post. I’m not going to give a list of nice typefaces for coding, either. You know how to Google things, plus, it can get subjective.

Some stuff just comes down to personal preference and what you become accustomed to, like a certain color scheme. I’ve literally spent hours choosing the colors that I want my HTML, CSS, Javascript and PHP to appear in my text editor. I love making color themes—again, another post. The reason a lot of programmers/coders do this is for quick identification of certain elements. You may be looking at thousands of lines of code, scrolling and scanning for a single comma that is breaking your code. So, if every comma is red that might be helpful. It might also be terribly distracting and difficult to read and probably not a great idea.

Color theme sample from http://ethanschoonover.com/solarized

Adding a bit of good typography practice can bump the readability of code. You can set the line height (or leading) in your text editor to give the words a bit more space around them. This gives your eye a bit more room to pick out a single line of text and focus on it. Some editors even let you configure certain combinations of characters to use a bold or italic version of the typeface. (More here on typography if you have time.)

All this color and typography stuff has been helpful for enhancing the coding experience so far, but what if there was MORE that could make it BETTER?

More, you say?

I’ve recently been dabbling in a bit of typeface design in my time outside of creative developing at work. All this close observation and wrangling of bezier points makes it hard not to pay attention to the typefaces I use when coding. After all, programming and markup languages are all still composed more or less of the same sets of characters, and I’m staring at type all day, though I’m not setting it.

It’s likely that your local typographer has read Beatrice Warde’s “The Crystal Goblet.” In this essay about typography, Ms. Warde (or B-dubs, as I know her) lays out some lovely prose about how type should act: it should be an invisible and unobtrusive presentation of wp-content. In other words, when you’re reading, you shouldn’t notice good typography at all, and the experience should be seamless. However, what if you need disruptions in text? What if you aren’t reading a novel but thousands of distinct lines that tell a computer do a thing? Reading code, in that context, means something closer to scanning and cherry-picking certain phrases, words, or individual characters, all while playing a game called “what’s missing here?” Instead of finely balanced characters that create a consistent block of text, you might need a tricked out, highlighted, half bold, half italic, crazy typeface that would make your local typographer weep openly.

Maybe for coding, we’re looking for something peppered with easily identifiable characters like versal letters on manuscripts back in the day (aka Medieval times). I see some cool ligature opportunities, like a double &&, or the chance to make oversized commas, braces and symbols. Could a text editor make use of OpenType features like contextual alternates and small caps? Perhaps a typeface design could indicate hierarchy in a sea of code without the use of color.

Maybe!

For the most part, typographic coding concerns (and seriously, who among us doesn’t have these?) are usually front end based. Making an <h1> look just right on a website, or spacing a menu in an app. My insight really doesn’t go any further than this here blog, but I’ve been kicking around the idea of designing an non-standard typeface for a while, so that’s something. I might even give it a try one day. All I’m saying is the next time you fire up your text editor, maybe you should think about this very blog post you just finished reading and have a real good look at the typeface BEHIND the typeface.

After you do that the one time, you don’t have to do it again unless you are super interested.

The post Vague and Unfinished Thoughts on Typefaces and Coding appeared first on Software for Good.

The work we produced at the end of Hack for MN was exploratory and a tech demonstration of what we imagined could be, which we code named “Vicini.”

Since the beginning of the Vicini project, we have not written much code. In fact, more energy has been focused on defining the needs and goals, meeting with Steven Clift, E-Democracy’s Executive Director, and continuing to explore the concept.

Earlier this month, the CityCampMN 2013 unconference provided an opportunity to engage more people who have an interest in a tool like this, continue the discussion, and find additional contributors.

Highlights:

• How do you include someone who is involved with the community, but for whom technology like smartphones may not be an option?
• How do you build trust?
• How do you maintain privacy?
• How do you create adoption while maintaining trust and privacy?
• The civic-minded and the tech-minded are not necessarily the same.
• Not all neighborhood blocks are engaged with each other. Some are because they like to be, others because of necessity.

Twin Citians provided valuable insight into community issues and where a project like this may or may not help.

The following day at CityCampMN was a coding session, where we focused on the baseline neighborhood directory feature and @stpaultim updated the Vicini project’s wiki to reflect the purpose and discussion from the previous day.

We also found two additional code contributors @ballPointPenguin and @jcummins in addition to the original team.

Vicini

• Roadmap & Planning
• Development
• Source Code

The post Software is Not Always All About Software appeared first on Software for Good.

Last week, I volunteered at the Grace Hopper Global Celebration of Women in Computing Conference. 4,600 women charging the streets of downtown Minneapolis was truly a sight to see, and even after only four days with them, I can honestly say that I have never met more inspiring, witty, and driven women in my life.

I spent my first day volunteering at the main keynote event: Sheryl Sandberg in conversation with Maria Klawe and Telle Whitney. My task was to make sure we filled every seat in the auditorium. As I was directing the sections closest to the front, I turned around to see Sheryl Sandberg herself, standing right behind me! Of course, I had to snap a picture.

I learned so much at the conference, but these two takeaways stood out:

The first was during the workshop with Patty Azzarello. She told the audience to stop trying to get better at things we aren’t naturally good at. Instead, put all of our energy into things that we enjoy and are naturally good at.

The second was during the panel discussion with Etsy, Pinterest, Fusion, and Airbnb. They talked about their scaling strategies and unique techniques for sharding their databases, which I found particularly intriguing.

Being a woman in this industry, tech conferences have always been fun but a little uncomfortable. Sometimes I left feeling insecure and left behind. At Grace Hopper, though, I left every day feeling inspired and empowered to reach for my dreams. I never felt overwhelmed but instead felt proud of where I am and of how far I’ve come since I started programming.

Even more exciting, on the final day of the conference, I was asked to join the list of speakers for next year’s conference in Phoenix, Arizona! I will be speaking on a panel with other women who build software “for good,” and I’ll also be a mentor during the Speed-Mentoring session.

Here’s to embracing who I am and enjoying this journey as a woman in computing! See you next year in Phoenix, Hoppers!

For more images of the conference, go here.

The post Grace Hopper Conference 2013 appeared first on Software for Good.

The class started with two visual exercises to explain the differences between waterfall and Agile approaches to project management.

Exercise 1: Build a Widget using a Waterfall Approach.

Rules: The team was spread across 4 stations and not allowed to speak with the other stations. The 2-3 people at each station were given a specific role and task and there was a project manager who pressured us and pushed us to perform, and we were to be timed.

I was at station one. Our task was to explain (without drawing) this figure.

It was hidden beneath a white bed sheet so the other stations could not see what it was. The second station had to draw out what we wrote. Third station had to assemble it based upon the drawing. When the drawing got to the next table the project manager advised table one (my table) that there was a change order. We cheated and walked to the next table and told them…but you’ll see later that the message never really got through to them in the end. Fourth station was testing and quality assurance.

Here was the end result…

This took our group around 25 min and we all felt rushed at each station. We all agreed that if we had more time we could have done much better. Most importantly, the end product looks nothing like what the client wanted.

Exercise 2: Build a Widget using an Agile Approach.

Rules: Very few. We had to self-organize and work together to duplicate a figure that was already built.

Liz set up one large table for us to work around. Since there were no roles, people were just going to have to figure out what they could do after the clients requests were given. She assembled the figure before we started, just like before, but this time we could all see the end result before the building began.

Some people naturally took on leadership roles and others just assembled each corner individually and then put it together with the other corners. About 2 minutes in she gave us a change order, and without getting flustered we fixed it in about 30 seconds. We all worked together, without confusion or wasted time, and we completed the task in 7 minutes. A perfect product was created and everyone was happy.

Wrap-up

I understand that this exercise is exaggerated and far from real life, but it effectively illustrated the differences between waterfall and Agile. Waterfall has process that is intended to guide the work, but it seems to just get in the way. It feels crazy why people would choose anything other method than an Agile workflow. Agile is fast, effective, and clean. Everyone knows what everyone is doing at all times, and you remain accountable for tasks you choose to do. You work together and communicate constantly, fail fast and refactor frequently.

There were a few other exercises that we did but they all boiled down to the same few lessons, agile is more adaptive, more visible, and more effective. Who would have thought the true simplicity of Agile project management can make such a large impact on productivity?

The post An Agile Example appeared first on Software for Good.

Some of my favorite moments, and a few words of wisdom that stuck with me:

David Ernst talked about his new concept Open Textbooks at the University of Minnesota and how it addresses the rising financial challenges for college students – especially around the rising costs of textbooks. David noted that student loan debt has risen above credit card debt in the US (now over 1 trillion dollars!) and many students now delay purchasing required textbook until they are falling behind in class. Open Textbook’s basic idea is to leverage Creative Commons and enable professors to find the books they need on the Open Textbook Catalog, take out only the pages they want, personalize it for their own course, and provide it to their students free of charge. I found this to be an exciting and innovative way to address the rising costs of textbooks.

My favorite Jamie Millard: Don’t Ask for Permission – reach out for your dreams and create your own opportunities. If you just graduated college or finished an unpaid internship/apprenticeship; you are no longer entitled to your dream job or a job at all for that matter. For example, you might apply for a job in social media and lose it because “we went with someone who knows illustrator and html!” Well don’t sit around and feel bad for yourself, go online and teach yourself. “Fake it till you make it, can sometimes very well be true,” Jamie said. She went through 5 unpaid internships, then taught herself the skills she needed to create Paper Darts, her literary arts magazine. Shortly thereafter, her dream job came looking for her her. What I got from this talk is that people should stop getting set back because people don’t think you are qualified. Go out there and learn how to network, hustle, and teach yourself skills online or at the library.

Krystal Rampalli then talked about Medical tourism – she explained about getting medical care abroad and the possible complications that arise. In one situation, a middle aged American man was in need of a kidney transplant. In the US there was an indefinite list of people ahead of him to get a transplant, but the doctors said not to worry because there are several other countries with no wait and exceptionally lower costs. Problem solved right? Not exactly. Krystal shared some of the unlikely complications that stood in the way of this kidney transplant, some of which would never have cross your mind.

You can see all of the talks from TEDxUMN 2013 on http://www.tedxumn.com  soon. I encourage you to attend or volunteer at next years event; it was a great experience and I met so many amazing people! Thanks again TedxUMN for letting me be a part of your special day.

The post TEDxUMN – 2013 appeared first on Software for Good.

Marti Nyman, the speaker at the meetup, is the Director of Innovation at UnitedHealth Group and is responsible for the growth and development of the company’s innovation portfolio (more here). Marti is leading the initiative at UnitedHealth to foster better relationships with local innovative health entrepreneurs.

Marti said that compared to funded health startups elsewhere, very little is money is spent in the Minnesota startup space. The competition and lack of funding in MN, however is and isn’t the issue. The solution? “Build a strong company and the money will come to you, not the other way around.”

Insider tips for creating a successful Health Care Startup:

• Do your research. Know the real problems for that have yet to be solved. If there is a “solution” already in place and you are trying to do it better, why is your solution better?
• Show you can cut major costs. If it’s just a marginal change in cost you won’t grasp anyone’s attention.
• Make sure you know the problem you are solving is a real problem. Prove it is real with evidence: market research and even a beta version you have tried with real participants.
• If you want to get in and speak with the large companies like Medica, BlueCross, Unitedhealth don’t reach out to the executives, you need to find and get ahold of the people that are in charge of innovation. These movers and shakers are the ones who might have the time to hear your pitch.
• Lastly, if you can change the health industry employee’s daily routine to make them more excited to go to work in the morning, it will make a positive impression.

Watch for the next meetup event here, or to stay up to date with what heath related startups are in the Minnesota at healthcare.mn —  make sure to checkout the map of all health startups in Minnesota.

If you are ready to start your own health startup, contact us. We are ready to be your engineering team.

The post Tips for an Innovative Health Care Startup appeared first on Software for Good.