Lately, though, we’ve been scheduling more of these half-day sessions with our software development clients, using them to dig into product strategy and explore ideas. It turns out that when we involve everyone in imagining what we could create, the hours fly by — with tangible results we can use to start building a new product.

Here’s how we keep four-hour meetings from feeling like a slog:

Stay rooted in purpose.

We start each strategy session with the question, “Why are we here?” The answer is never “to build an app” or “to redesign this website,” but statements like “helping people plan for the future” or “empowering people to ask the right questions.” That helps us connect to the mission of the organization and the ultimate purpose of what we’re developing.

Imagine the goal together.

An activity we often do early on is to have everyone around the table list adjectives to describe the planned application or website. Collecting words like “friendly,” “authoritative,” or “simple” help us get excited about a shared vision.

Get out the markers and draw.

Asking adults to draw can be anxiety-inducing, but the Crazy 8s design sprint is about getting ideas down on paper quickly, not showing off artistic prowess. This activity from Google asks each participant to fold a piece of paper into 8 sections and then draw 8 sketches of features they recommend for the product — one minute for each sketch, one right after the other. Then each participant takes turns explaining their sketches. For example, one person might suggest a chat function in the application, while someone else might suggest a tracker to visualize progress towards a goal. Finally, the group uses stickers to vote on their favorite ideas.

Crazy 8s is a light, engaging way to open up a bunch of ideas and possibilities. It allows everyone in the room to contribute to a list of product features, which the group can then narrow down.

Put yourself in your users’ shoes.

Brainstorming product features is fun, but to narrow in on what’s essential, we have to think about the product from the perspective of the people who will use it.

Once everyone has started thinking about features through the Crazy 8s activity, it’s time to start compiling the full list of required features. For this, we use story writing. Participants spend time individually writing stories on notecards using the format “As a [role], I want to [do something] so I can [accomplish a task].”

As everyone shares the stories they wrote with the full group, we organize them into categories, grouping related features. Then we sort all of the stories into three buckets: must, should, and could. The “must” stories becomes our to-do list for development, our list of features necessary to create the minimum viable product, or MVP.

Leave with a promise to share updates quickly.

What makes this four-hour meeting fun is that it’s hands-on and collaborative. We don’t come up with an elaborate pitch; we brainstorm and discuss ideas together with the client team.

That also means that the four-hour meeting has momentum — we know that what we’re creating will lead directly into software development, whether we start working on the product right away or hand off the features list for the client to decide what to do next.

If Software for Good does start on development, we’ll continue to work closely with our client for constant feedback and iteration. So after sitting through a four-hour meeting, no one has to wonder whether the discussion and ideas will go nowhere; instead, there’s a concrete view of what comes next.

By keeping the purpose and the end goal in mind, plus staying active and creative, we’ve been able to make meetings fun — yes, even for four hours.

The post How to Make a 4-Hour Meeting Fun appeared first on Software for Good.

Static Versus Dynamic Actions

There are two types of quick actions: static and dynamic. Static actions for an app are defined in a project’s Info.list file, and don’t change. Dynamic actions, meanwhile, are defined at runtime and can change (based on user actions, for example). Although only static actions were needed for our purposes, we decided to implement our actions as dynamic to avoid the “stringly” nature of defining them in the Info.list file. This also allows us to implement dynamic, changing quick actions in the future.

ShortcutManager

We created a Swift struct named ShortcutManager with just two methods:

func shortcutItems() -> [UIApplicationShortcutItem]
func handle(shortcutItem: UIApplicationShortcutItem) -> Bool

The first method provides an array of our three UIApplicationShortcutItem objects, and the second one is called from the app delegate when a user taps on a shortcut item. One UIApplicationShortcutItem corresponds to a quick action. The second method changes tabs based on the identifier of the shortcut item.

Because our app still supports iOS 8.0 and home screen quick actions are exclusive to iOS 9 and above, the ShortcutManager is declared to be available for iOS 9.0 and above only, by adding @available(iOS 9.0, *) on a line above the class declaration.

An enum is used for the shortcut identifiers:

enum ShortcutIdentifier: String {
  case openMap
  case openEvents
  case openParade
}

And a UIApplicationShortcutItem is defined in shortcutItems() as such:

UIApplicationShortcutItem(type: ShortcutIdentifier.openMap.rawValue,
                          localizedTitle: "Map",
                          localizedSubtitle: nil,
                          icon: UIApplicationShortcutIcon(templateImageName: "map_icon"),
                          userInfo: nil)

In the app delegate, the shortcut items are set like this:

if #available(iOS 9.0, *) {
  application.shortcutItems = ShortcutManager.sharedInstance.shortcutItems()
}

Similar to @available(iOS 9.0, *) earlier, using #available(iOS 9.0, *) causes the code in the conditional block to run only if the device has iOS 9.0 or above.

Handling shortcut item selections happens like this:

@available(iOS 9.0, *)
func application(_ application: UIApplication,
                 performActionFor shortcutItem: UIApplicationShortcutItem,
                 completionHandler: @escaping (Bool) -> Void) {
  completionHandler(ShortcutManager.sharedInstance.handle(shortcutItem: shortcutItem))
}

With quick actions defined dynamically, we can display a quick action to access the next upcoming event or provide directions to the festival based on user location in future versions of the app.

Twin Cities Pride 2017 is available for iOS and can be downloaded here.

The post Implementing Home Screen Quick Actions in Swift appeared first on Software for Good.

Iteration 1: Designer without a Concept

Long before we landed on a group theme, the task to design a Pride t-shirt for Software for Good was felt daunting. I had no limits, but freedom can be paralyzing. With only the visual language of our organization as a jumping off point, I sketched some shirt designs around ideas like tech and computers and rainbows and pop art.

A single question guided my process: would I wear this shirt? Would I be happy to put it on after the parade, or would it be banished to the nether reaches of my dresser? In this way, I was totally satisfied with my first round of designs, although they fell apart under conceptual scrutiny.

They were what they were.

Shortly after I completed the first round of concepting, Software for Good met with our partners at Buzzfeed and Clockwork to discuss ways to bring all three organizations together around a central theme. I presented the ideas I had been working on and got some feedback that I totally agreed with – the shirts were nothing special. We needed a unifying element, a rallying cry, something to bring it all together. We all went back and forth on a number of different concepts, but we eventually landed on “Plug in to Pride.” I was ecstatic – finally, an idea! With a tagline and much-appreciated deadline, I went back to the sketchbook to figure out how to bring this concept to life.

Iteration 2: World of Plugs

I like to create constraints and systems to allow myself to work smarter. Most of my practice at Software for Good revolves around leveraging existing design patterns and systems to create new apps and websites at breakneck speed. Unfortunately, the same processes don’t play very well with more traditional graphic design projects: whether it’s a poster or a shirt or anything tactile, the only thing that really makes for a great result is time and experience. With a theme in hand, I was free to ideate and bounce ideas back and forth to really achieve something wonderful. In this case, the idea of ‘plugging into pride’ immediately struck me as something to leverage. What are we plugging in? It’s a cute and cheeky at the same time. And it’s active. My mind immediately went two ways: plugs and cables. Software development can be esoteric, but everyone’s plugged something in at some point. With this insight, I moved forward with the next round of revisions and presented them to the group at our next meeting, where I gathered a lot of valuable feedback.

I tend to gravitate toward simplified, geometric and iconic line work and bold typographic choices. This aesthetic seems to carry with it a kind of ‘love-hate’ attitude from clients. Some thought this version looked too retro, which I gladly conceded while simultaneously hiding my new Draplin Design Co. book. Others thought that it kinda looked like Minnesota, but not enough like Minnesota to really work as a concept. The most interesting piece of feedback, though, wasn’t about the aesthetics of the illustration, but the mechanics of the cable. “It’s hetero,” someone said. And that’s totally true. I didn’t even realize it. You’ve got a male and a female end of the cable right there in plain sight. So how do we solve that? The last thing I wanted was to broadcast a heteronormative viewpoint at Pride Festival, (check out my first blog post if you want some good soap box action) so I took the concept back to the drawing board.

This concept was probably the safest and least exciting one to work on (everyone else agreed, too), but it served an important purpose in relation to the final design. I knew I wanted to do something with the Minnesota motif. If Minnesotans in big gatherings love anything, it’s Minnesota. Using it as a framing device for the flag, coupled with some bold typography, helped ground further revisions into what became the final design. Still, some thought this design had some merit. “What about rainbow cables?” they said. What about them…

For this concept, I created a pattern system consisting of custom-illustrated male and female ports that I thought would be recognizable to anyone who’s spent any amount of time near a computer. HDMI ports, USB ports, power ports, DVI ports, DisplayPorts. The tech is used  conceptually as a tongue-in-cheek reminder of how we plug in on a daily basis, while the diversity of the types of plugs is a nod to inclusivity and diversity. Structurally, this concept was my favorite. Good design functions both at a distance and up-close. With this design, the viewer receives the message from a distance, and the joke up-close. However, the pattern didn’t seem very active. I knew it was on the right track, but not quite there.

Iteration 3: Figuring it Out

After receiving an additional round of feedback on the concepts I presented, I tried to flesh out each one into something we could choose for a final. I put equal time into each one, trying to come back to the table with three solid revised concepts that could be sold equally. Nothing’s worse than a client picking your least favorite idea, so only present work you’re proud of!

Maybe I got a little carried away with the revision of this concept. I got rid of the hetero plug and replaced it with plugs of all kinds. Inclusive plugs! Male to male, male to female, female to female. I also lifted the rainbow type from the other concept to reduce the amount of visual clutter a little. Still, this concept started to feel a little busy. I like the way the plugs interact with one another and the type, but it wasn’t my favorite. After all that work, this one was passed over.

I still really love this concept. I took the idea of rainbow cables and ran with it, creating an outline of Minnesota that had no beginning and end, with plenty of cute little corners and swirls. I really enjoy how the outline interacts with the type, but when I brought this design back to the table, it suddenly didn’t read quite enough like cables. “We need a plug on it,” someone said. If we did that, we’d be right back where we started with the hetero plugs from before. Sometimes design can feel like a circular exercise.

Here’s where it finally started to feel like I was getting somewhere. The use of Minnesota as a framing device for the ports really helped the design feel complete. However, the state outline still felt like it was getting lost around the edges. Additionally, I received feedback on the use of the uppercase “I” vs. the lowercase “i” that needed to be addressed before we could send the shirt off to the printer. Nevertheless, here it was: plug into pride!

The Final Shirt + Odds and Ends

The identity was extended to the truck float that marchers followed during the parade, and I couldn’t be prouder of how it all came together. We marched in solidarity with our LGBTQIA friends and as a commitment to showing up and building a diverse and inclusive tech community.

The Takeaway

When you have to work quickly, you have to make quick decisions. Nevertheless, the final product is only as good as the amount of work you put into it. Be proud of your work and take ownership of getting it done. I went through tons of sketches, hit plenty of brick walls and had plenty of perfectly fine concepts get scrapped in the name of making the best work I could. Keep your work, show your process and always be open to iteration and feedback.

Have any questions? Reach out to me, I’d be happy to chat! Hit me up at kyle@softwareforgood.com.

The post Plug in to Pride: Designing a Rallying Cry appeared first on Software for Good.

Who among us has not experienced a website whose vision of excellence was never quite achieved? Someone who gave up wrangling too many stakeholders and a distraught writer, vowing to get everything back on track in “phase 2.” And, in the end, settling for a website that, while less than desired, was at least… finally… done.

It is possible to plan and write a website on budget, within your timeline, and to your expectations—if you take the time to heed these five key reasons web content can derail your dream site.

#1 The existing site is not fully reviewed for content needs.

It is not enough to say the site is 25 pages. Each page planned will vary in terms of the availability of existing content and the need for interviews or research. An audit of the existing site, or the existing information, must take place before writing begins.

In many cases, the information is outdated or wrong, and new content will need to be created from interviews, research, and other sources. No problem if this is accounted for in the timeline. Expect a minimum of eight hours for creation and revision of a single, high quality “scratch” page. Pages simply needing reshaping to fit the new tone and personality will require significantly less time.

#2 Key stakeholders don’t agree on key messages prior to writing. (Or worse, they aren’t paying attention and give haphazard direction.)

In this unfortunate scenario, writers should stop the steamroller and make sure they get agreement and attention before they begin to write content. Writing content as a Rorschach test for clients’ reactions is a disaster waiting to happen, and is likely to be highly inefficient.

It may be obvious, but writers can’t read minds. It’s not fair, and it can be costly, to let writers guess at priorities and proof points, only to be way off from that which clients were hoping to see. Again, seeing what the writer came up with, in absence of clear direction, should not be a starting point for stakeholders to gain clarity.

People are busy, and companies want their new website up fast. This can often lead to rushing the most important part of the copy—content strategy and planning. Outlining specifics of key messages, points of information that must be covered, explained, or listed, and making sure pages have unique content, is best done before the writer hits the keyboard. The writer may have a strategic background, or there may be a need for an additional content strategist to help with this step.

#3 Writer fails to grasp the company’s personality and does not understand the customer experience that will follow from a web call-to-action.

Writing a website is like writing a novel. The tone, personality, terminology and verbiage must be consistent throughout. It requires strong interviewing skills, to get not only the basic information for the page, but also examples and specifics around those main ideas to bring the copy to life.

Most organizations now know that their website is the first point of contact for potential customers. It needs to be easy to read, yes, but if it lacks cohesion with the company’s personality, the potential for enticing customers will be lacking. It is critical that the web content portrays the personality that potential customers will encounter when they visit the company in person, or talk to a representative on the phone.

At least two scenarios are possible. 1) The web content lacks sufficient personality to draw customers in, or, 2) dissonance is created in the mind of the customer between the computer screen image and the real image of the company. Whatever you write about must not only entice, but must build real expectations for working with or buying from the company. Fall flat, and no one will bother going further; oversell and you risk disappointment when they first encounter your business.

#4 Timeline isn’t firmly established or agreed upon upfront by both writer and client.

Writers need deadlines, and so do clients. Everyone should understand that if deadlines are missed, the site launch date will inevitably be delayed. A timeline should be established and agreed upon by all parties, and a project manager should be assigned to keep everyone reminded of their deadlines and make sure everyone has what they need to meet the agreed upon deadlines.

Websites often have extensive copy, so timelines must run in “batches” or “sprints” in order to keep the project moving and to get approvals as you go. Depending on the site, batches could be set according to top priority, or aligned to sections of a site, types of content, or leading with key pages to firmly establish tone and personality. However you plan to execute copy, consider how completion of one batch may set a tone for others, or how the order should logically proceed for best outcomes.

#5 Client needs too many “deciders.”

Many organizations want input from too many people to ever get copy finalized and onto the screen for customers. Set a client group of no more than five stakeholders, and assign a single person to aggregate everyone’s feedback and resolve conflicting stakeholder opinions. By doing this, the writer gets clear and comprehensive feedback for each batch at one time.

Beware of the stakeholder who wants to rewrite copy on their own. It is best if the writer or project manager helps frame how the feedback should be sent. For example, ask clients to offer content revisions in the form of 1) edits, 2) corrections, 3) reframing, 4) deletions, 5) highlights, and/or a “we need to talk” flag for significant rewrites. It is better in the long run to help the writer solve the problems, rather than allowing individual stakeholders to rewrite sentences or make actual changes in draft copy. Conversations and suggestions are far more helpful to get the writer “on board” than simply telling them what to write.  And, when other people write corrections, they rarely match the tone of the paid writer.

There are, of course, other ways a web site can get off track, but managing these five potential pitfalls can help you plan and execute your site in a timely manner. As a writer, it is important to watch for these red flags, and do your best to make sure the project is well managed before you estimate. Then, if everyone stays the course and keeps to their deadlines, the site will come together without conflict or significant disruption, and you’ll be happy to celebrate a job well done with the entire team.

—

Liz Lacey-Gotz is principal at Liz LG LLC and senior writer consultant at Union Park Marketing. Liz is a content strategist, writer, and branding specialist with 20+ years experience. She has written sites for Robinson Fresh, C.H. Robinson, MelonUp!, Capella University, Minnesota Waldorf School, and more, as well as other digital and print communications for companies of all sizes.

The post 5 Reasons Content Can Derail Your Website Launch appeared first on Software for Good.

All endpoints and data remain the same. Near realtime events (substitutions, goals, cards), as well as results by team and group.

During the 2014 World Cup, the API was called over 13 million times and over 240 files on Github referenced it. We saw apps built that displayed the score on the current game on an analog display, command line apps, Android and iPhone apps, and a slew of web apps. Best of all, a number of teachers wrote us to say they were using the app to teach JSON parsing to their students!

We can’t wait to see what you’ll build with the data for the Women’s World Cup! Now come on USA, beat Australia!

The post Updated World Cup API appeared first on Software for Good.

This is painful. It is unhelpful. And worse, it is entirely wrong tactic to solve your underlying problems: Uncertainty in how software development works. Uncertainty in how much it costs. Uncertainty in what is harder (i.e., more expensive) than other parts.

So how do you resolve uncertainty?

Find a partner you trust, and get started.

No really. It’s that easy. This is going to sound flippant, but it is really easy to get started on your project: Step 1) Introduce yourself and your project to us. Step 2) Get the paperwork completed so any work we do for you is owned by you. Step 3) Start the project.

But the budget!

What you do not know yet, is that we do nearly all of our projects as time and material engagements. What does that mean? It simply means that when you ask us to do work, we track the time it takes us to complete it, and invoice you the time. We break down our work into 15-minute increments. And the materials bit? If we buy a special plugin or software widget to enable us to spend less time building something for you, we will ask that you pay for the widget. Don’t worry, we won’t buy it till you approve the expense. There will not be any unexpected costs here.

So where does this leave you? In complete and total control of your project. How great is that? We get started. And if it isn’t working out, or it is more complicated than originally thought, well then you get to decide what to do next. Keep working? Great! Stop and think about it for a while? No problem. Unhappy with the work we’ve done? Sorry to hear that, that was our mistake. But the good thing for you is that you have a copy of all of the wireframes, code, design files, backlog of tasks …. You own everything we created. You can take it anywhere you like and continue right where we left off.

What are you waiting for?

You have an awesome idea. Let’s start with a small budget — just enough for you to learn a little bit more about what you want to build from the professionals. And if that works out, maybe we go a bit farther.

We can’t wait to discover where your great idea leads you (and us!). Let’s make it happen.

The post Get Started Already. Worry About Stopping Later. appeared first on Software for Good.

The post All Estimates Are Lies appeared first on Software for Good.

As you probably don’t remember, I was last year’s resident word nerd at Software for Good. Since leaving, I’ve moved far from snowy Minnesota, enrolled in a software development school, and built some pretty wild programs that I never thought were possible.

I could write a whole post entirely about Software for Good’s support as I’ve journeyed down this web dev path. Instead, I’ll just say wholeheartedly that every success I have is thanks to their examples and encouragement. The team showed me that writing code is so much more than just cranking on keyboards. That building an app is a tedious yet enthralling process. That design should drive not only the front-end experience but also the back-end architecture.

Most memorably?

That tech vernacular is ridiculous, hilarious, and largely unintelligible to folks outside the know.

Below, I present to you a section from my official “Overheard at Software for Good” document, also known as the list that encouraged me to pursue software development because I legitimately had no idea what my coworkers were ever talking about.

On Unicorns

“Restart the unicorns.”

“So, it’s not just unicorns we’re talking about now.”

“Ahh, it was a zombie unicorn issue.”

“Kick the unicorns down!”

“In any case, it’s easy peasy. Just add another unicorn.”

“You need some unicorn action up in here.”

“Which unicorn?”

“I just kicked the unicorn. No good.”

“Unicorn kicked. Seems good now.”

“I haven’t bumped the unicorns yet.”

“Bouncing unicorns. I’m trying to bounce unicorns.” 

“Yeah, I bounced the unicorns. I bounce the unicorns about once a day.”

“The unicorns are sad.”

“If I restart the unicorns, it works fine!”

“The unicorns just don’t respond. They just sit there and do nothing.”

Yep. From an outside perspective, Software for Good is an office full of people who abuse unicorns. Sorry, Peter.

What can I tell you now about unicorns? Here’s what I gather:

Unicorn is an HTTP server for Rack applications. It makes fast things move even faster. From what I understand, the main crux of Unicorn is that it splits up tasks, placing the focus on one major port, then delegating all other client requests to forked worker processes.

Pause. Forked? Not the utensil. Basically, something that’s been forked is something that was created as an independent entity simply by copying the entirety of something else. So, if you take this blog post, copy it, post it to your own blog and make a few changes, you’ll have a kind of a “forked” version of the original. (Please don’t actually do this.)

Anyway, within those forks, Unicorn finds and restarts broken workers, thus eliminating the need for a non-magical human to manage that tedious part of an app.

Pause again. What’s a worker? Basically, it’s a (union-friendly) term for a something that automates a repetitive task. In technology, functionality breaks. Dependences change. All kinds of surprises arise. Something that can swoop in and not only tell you what’s broken but also fix it is your best friend. Unicorn is your best friend.

Sometimes the unicorns are slow, though. They require a lot of memory. Fortunately, you can kill the unicorns, which is a really awful way of saying: Fortunately, you can restart the unicorns. With a simple install of the ‘unicorn-worker-killer’ gem, you’re all set to go. The gem automatically restarts the unicorns based on the maximum number of requests and the maximum memory allocated.

That’s all I’ve got for now. I’m still a little unclear about those Software for Good zombie unicorns and unsurprisingly, Google’s not helpful. Hopefully I’ll figure it out soon enough, then I’ll swing back around for a Halloween-themed guest post next October.

—

Check out Sara’s fantastic Course Report interview about her experience at Turing School.

The post “The Unicorns are Sad”: Tech Talk and the Workers Overheard 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.

The end product? A free, publicly available JSON API. An API that (humble brag) hung out at the top of Hacker News for quite some time earlier this week.

It happened 1) because Eric is super cool and 2) because Casey founded a company that encourages super cool people to do what they love.

I’ll be the first to admit: it’s very easy to forget this second part. When I’m so focused on work, I get lost in the shuffle. I help to get some really challenging and exciting and do-good work projects out the door and into the world, and it’s great. Actually, it’s more than great. It’s a really awesome way to make a living.

But getting lost in the work shuffle makes it really easy to forget that I have my own interests, too. More importantly, getting lost in the work shuffle makes it really easy to think that by doing anything else, I’m being a bad employee.

Honestly, though?

Working on a side project doesn’t make me a bad employee. It makes me a much better one.

Eric’s API was an excellent reminder that the very best projects stem from passion. He had an idea. He legitimately didn’t know if a solution was possible. He decided to give himself the challenge. He found a way to make it happen, then he worked until it did.

There are a thousand different ways Eric grew from the project, both as a software developer and as a soccer fan. (He wrote about them all here, by the way.)

It’s rare to find people who have Eric’s kind of drive—people who seek out difficult challenges and take them on willingly, with grace and enthusiasm, without assignment or promised reward.

These are the people who come up with the most interesting answers. The people who focus on finding long-term solutions instead of quick fixes. The people who have the guts to embrace complicated issues with diverse perspectives and toolboxes. The people who mentor. The people you want to be around. The people you want to work with. The people you want to learn from.

Here at Software for Good, we want these people. We want an entire office full of these people. We’d be crazy not to, and we’d be crazy not to support them the very best we could.

The post Find Cool Projects. Run With Them. Run Far. appeared first on Software for Good.