As a company, we’ve worked to learn and document best practices for inclusive apps and websites. On April 18, I got to share some of that learning in a talk for Cafe Conversations, an event hosted by Young Nonprofit Professionals Network (YNPN).

The talk included many insights we’ve learned from accessibility experts who have personally faced barriers to using tech and the internet. I made sure to highlight organizations like WeCo, and shared some of the insights they presented at World Usability Day.

A few pieces of advice we shared:

Use familiar tropes and consistent layouts to help visitors find their way around your site or app.

Taking up more of a user’s time and mental load will make them feel frustrated or simply give up. (One of the most influential books in user experience design is literally called “Don’t Make Me Think.”) Common tropes can help people achieve their goals more quickly — for example, icons like a magnifying glass for search, or layout elements like clicking on the organization’s name in the top left of the screen to return to the home page.

You can be creative with some aspects of design, but when people expect certain functionality and cues, don’t force them to work harder.

Be respectful of people who may be in crisis, or just have limited time and energy.

We never know what our users are going through — they may be distracted by a busy environment, frantically looking for help during a crisis, or dealing with personal loss. They’re likely to be upset and alienated by insensitive language or images, or a tool that doesn’t account for their specific situation.

When an app or website is built with respect for all of the circumstances its users might be facing, it’s more likely to be welcoming and easy to navigate. It’s often said that improving accessibility for people with disabilities makes apps and websites better for everyone. That’s true of people facing other barriers, too.

Think about how to make your content available offline, for people with unreliable connections.

Millions of Americans lack reliable high-speed internet — so requiring a strong, consistent connection to use your site or app will exclude many people, especially those who live in rural areas. If there’s information your users will need when they might not have internet access, can you provide a downloadable version for offline use? If you’re creating a mobile app, are there static screens or elements that can be cached and set up to load without connecting to the internet?

With any downloadable content, it’s important to remember that PDFs aren’t accessible with a screen reader, so anything provided in a PDF should also be available on the website itself.

You don’t have to figure this out alone.

One theme that emerged during Cafe Conversations: We’re not alone! There are countless online guides, blog posts, videos, free tools, and other resources dedicated to making websites and apps more accessible and inclusive, as well as consultants who specialize in the topic.

Many tools that make the web more accessible, such as automated screen readers and the ability to increase the font size on a site, are built into standard operating systems and browsers.

A few resources we’ve found helpful:

• Web accessibility tutorials from World Wide Web Consortium, the organization that manages the Web Content Accessibility Guidelines: https://www.w3.org/WAI/tutorials/

• WebAIM — Web Accessibility in Mind: https://webaim.org/

• “Usability Guidelines for Accessible Web Design,” Nielsen Norman Group: https://www.nngroup.com/reports/usability-guidelines-accessible-web-design/

• Tool to see how a site would look for people with colorblindness: https://www.toptal.com/designers/colorfilter

• Info about screen readers, including built-in readers on devices: https://abilitynet.org.uk/factsheets/introduction-screen-readers

• “Respectful Collection of Demographic Data,” Sarai Rosenberg: https://medium.com/@anna.sarai.rosenberg/respectful-collection-of-demographic-data-56de9fcb80e2 — there are many similar guides but this one covers a lot of ground and has helpful examples!

• “4 Design Principles for Gender Identity & Inclusion,” dscout: https://dscout.com/people-nerds/4-design-principles-for-gender-identity-inclusion-and-how-to-get-them-implemented

• “A Quick & Easy Guide to They/Them Pronouns,” book by Archie Bongiovanni and Tristan Jimerson: https://www.indiebound.org/book/9781620104996

• Stock photo sites that provide greater diversity: Tonl: https://tonl.co/, The Gender Spectrum Collection: https://genderphotos.vice.com/

• WeCo: https://theweco.com/

• Accessible360: https://accessible360.com/

The post Being Inclusive Online — Cafe Conversations with Young Nonprofit Professionals Network appeared first on Software for Good.

If you’re thinking about custom tech but not sure about the money, try starting with one of these strategies to make a software project more affordable.

1. Start small.

At Software for Good, we use the Agile methodology and Lean Startup model of building software. We develop by iterating, building a few features at a time and making changes as we go along. And we shoot for a minimum viable product, an initial finished version that can go public (or at least be tested with real users) as soon as possible. Focusing on the MVP means thoughtfully prioritizing the features that are most important.

It’s a lot easier to fit software into your budget when it doesn’t have to be big and complicated and perfect right away. You can start small with a simple minimum viable product, begin using it and getting feedback, and then build on it with new features over time.

2. Talk to lots of users upfront.

The biggest waste of money in software development happens when time and effort are spent on tech that no one actually wants. Maybe you think your audience needs a chatbot, but really they just need a more user-friendly contact form. Maybe you’re trying to organize information in a helpful way, but you’re using jargon that is completely foreign to the people you serve.

Avoid unnecessary expenses by talking to potential users before anyone starts designing or coding. Reach out to people likely to use your application, and ask about their likes and dislikes and needs. Send out surveys; sit down with people in person. You’ll challenge your assumptions and be able to focus efficiently on what’s most important.

3. Upgrade your online presence.

Start testing the waters for new software by making simple, low-cost improvements to your existing online presence. Create a schedule for updating and maintaining your social media and website on a daily, weekly, or monthly basis. Review all your channels to see who you’re reaching and which messages are working well, or pick one channel and focus on improving there.

Covering these basics helps you refine your message, interact with the people you serve, and set the stage to roll out a new website or application.

4. Take your idea to a hackathon.

At hackathons, teams of developers, designers, and people from every sector collaborate to build new technology. If you’ve got a problem to solve and an inkling of how tech could help, try pitching it to fellow participants. While you won’t walk away from a hackathon with a ready-to-go application, you can get feedback on your idea and an exploration of how it would work technically. You might even get to help build a working prototype that you can show to your coworkers, your board, potential funders, and eventually a team of developers.

Never been to a hackathon? The Twin Cities hosts a few that are focused on social and community issues and open to all comers, including Geo:Code and Code Switch.

5. Apply for grants.

Are you dismissing the idea of custom software because of the money? Don’t worry — there are ways to raise funds without digging into your own operations budget. If you have a clear sense of how technology will further your mission, you can apply for grants to cover the cost.

Here in the Twin Cities, the Shavlik Family Foundation focuses its grantmaking on helping nonprofits implement technology. A custom software project could also fall under grants for innovation, community engagement, or launching a new program. No matter what you’re applying for, taking time to think through your goals, users, and potential features first will help you make a compelling case for funding.

6. Fundraise.

You can also raise funds from your supporters to cover a new web or mobile application. While crowdfunding and more traditional fundraising campaigns certainly take time and effort, it can help to focus an appeal around a tangible project. Again, you’re more likely to be successful if you have a good sense of your goals and users — and perhaps even a working prototype — before launching a campaign.

7. Find a program designed to offer software on a budget.

Software firms sometimes offer discounted software for mission-driven organizations. Software for Good’s giving and internship program is designed for just that: We work with organizations with a purpose while offering paid, hands-on experience to software development interns. Learn more here about our program and see if it’s a good fit for your org.

8. Add technology to your strategic planning and budget.

A common thread here is that software projects are most successful and cost-effective when organizations think through the purpose and strategy upfront. Before jumping into development or pursuing funding, ask: How do you see technology helping you reach your goals? What problems are you trying to solve? What could a web or mobile app help you accomplish, and how does that relate to other programs, funding cycles, and the needs of the people you serve?

Better yet: Make these questions an ongoing part of your strategic planning and budgeting. You can start to see technology not as an extra expense, but as another tool to help you achieve your mission.

The post 8 Creative Ways to Make a Software Project More Affordable 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.

Why I Made the Jump

First, why did I choose to move from a MacBook to an iPad? There were a lot of little reasons, but simple curiosity was the biggest one. Could I make it work? Where would I encounter challenges? Would any of them be show-stoppers? And what would I learn about my computing habits?

Add to that a timing issue at Software for Good: my MacBook Air’s lease was up. It was time to figure out new hardware one way or another, and while the new MacBook Pros with their fancy new TouchBar looked nice, 1/3 the price for an iPad and a bit of adventure was calling.

Plus, I believe the future of computing will focus more on tablets than traditional laptops, and I wanted to get a head start on figuring that out. This was further underscored by Apple’s lackluster delivery of new hardware in 2016. And of course Apple’s business is significantly weighted toward the iPhone now, so we can expect them to invest heavily in the iOS ecosystem. It’s a good bet that any cool new features will start in iOS first.

Hardware Kit

So what did I end up with? I’m running the 9.7-inch iPad Pro. It has 128GB, and I opted to go without the cellular since it is easy enough to tether to my iPhone on the rare occurrence that wifi is not available. I purchased an Apple Pencil for experimenting, but the Logitech CREATE Backlit Keyboard Case was essential for making this a true productivity focused machine.

Software Kit

So much software! I won’t list them all out here, but a few key pieces that I use heavily every day.

OmniFocus: For keeping track of my own to-dos and followups, and progressing personal goals
Asana: For keeping track of my team and project to-dos
Slack: Communicating with coworkers and clients
Notes: I type all of my notes from every meeting. Searchable, flexible. This is an amazingly powerful bundled app.
Workflow: This holds a lot of promise in automating some pretty neat things. I have a couple ways I use it, but could use it a lot more.
Screens: This is my fallback. It lets me remote into a traditional computer (from my iPad) when the iPad native apps just don’t cut it.
Google Docs & Sheets: Why pass files around when they can just live in the cloud?
Working Copy: Editing code, saving contracts, and interfacing with GitHub

Benefits and Observations

So there are the obvious benefits. The 9.7 iPad Pro is smaller and lighter than most laptops—even when you include the pencil and keyboard case. It feels less intrusive in meetings. Major portability win here. And the battery life is stellar, though I still haven’t gotten used to not plugging it in when I’m at my desk.

But what else works well?

Native Apps
Web apps work fine, but I look for native apps first. Only downside: if the native app isn’t as feature-complete as the desktop counterpart, I get frustrated. (Harvest app for time tracking, I’m looking at you.)

Sharing using the built-in share sheet has been a slow amaze. Pushing a web link into a Slack channel, sending a file from the Dropbox app, or sending a team email with a templated status report I typed up in the Notes app—this all feels so much more natural with the share sheet than the drag/drop or copy/paste world of macOS. It isn’t perfect yet, but this new way to move information around and connect apps is awesome.

Workflow is another nifty app. One fun script I wrote lets me send a whole set of private messages to everyone in my Slack team, all at once.

I absolutely love the full-screen apps with the occasional split view. It helps me focus on the task in front of me, and see it through to the end. I tried to run all full-screen apps on macOS, and it just never quite worked. Lots of swiping to find the app I needed, and distractions kept popping up. I found myself dropping back into the windowed mode—which I hate—because I was constantly shuffling windows around to find the perfect placement, only to have it entirely upset as soon as I plugged an external monitor in. (Yes, I tried those save-the-position-of-the-windows apps. None of them work well.)

Intentionality
The lack of distractions in iPad computing truly surprised me. I find that when I sit down at my iPad, I have to think: Why am I here? What do I want to work on? This level of intentionality is something I never worried about on macOS. You knew what to work on next because when you closed one app, there was always another one right underneath waiting for your attention. It was more like whack-a-mole than intentional and methodically planned work. With the iPad, I first have to decide what to work on, then do it.

Challenges

Before I could fully let go of having my own macOS computer, I needed to track what didn’t work well and plan for those limitations. I created a list, which is long and mostly filled with weird, esoteric issues. They mostly fall into the “annoyances” bucket and not the “show-stopper” bucket. It’s a decidedly strange list of limitations, and not worth sharing here.

However, I’ve found one shortcoming particularly difficult to manage: video conferencing. This is the biggest issue I’ve had to date with the iPad.

Yes, I can video conference from the iPad. WebEx, Google Hangouts, Zoom, and FaceTime all work well. But when you’re running a meeting and need to do something else at the same time? Total fail.

All video sharing stops as soon as I switch to a different app—for example, switching over to Notes to capture meeting highlights, or quickly looking something up in the browser. Things one expects to do when on a video call.

The only exception is FaceTime, which works beautifully and does the picture-in-picture thing fabulously. Unfortunately, it limits you to only one other person in the call at a time.

I can’t use any external cameras, monitors, microphones, or speakers. (Well, sort of. If I had a Bluetooth speaker/microphone, and an Apple TV to AirPlay-mirror to, then most of this would be okay.) But the conference room I use has USB-based and HDMI-based equipment. And if you point the iPad camera at the room to get everyone in the picture it gets to become a pretty awkward angle to use the iPad for anything else. Which wouldn’t work anyway (see previous point).**

And sharing your screen through a video conference is not possible. At all. Under any circumstances.

I have found a small workaround for some of this: a desktop tripod stand that makes my iPhone a decent video-conferencing hub. This doesn’t solve all of the problems, but it does allow me to video conference with one device while taking notes on the other.

**I just learned that the Lightning to USB 3 Camera Adapter and the Lightning Digital AV Adapter could solve both the USB-based microphone and HDMI-based TV problems, though not at the same time. Clearly I need to research this problem a bit more.

Is it worth it?

Yes. Absolutely. I’m thrilled to see what is possible and to be forced to think about old problems in new ways. There have, of course, been a few times where I was under pressure for a faster-than-normal turn-around and I didn’t appreciate the learning opportunity in front of me. But most days I find the iPad has rejuvenated my love of solving problems with computers. It’s interesting and fun, and feels more efficient as I learn new ways of working.

Would this be good for everyone? No, not today. You need to look closely at the jobs you ask your computer to perform, and then see if iOS can work. In my position, 95% of tasks can easily be done on the iPad, and I’ve found adequate work arounds for the remaining 5%.

If you spend your days in something like Xcode or a desktop-only type of app, it’s not the right time for you to make the switch. Hang tight, though. I have confidence that the list of tasks you can’t do on an iPad is going to get smaller and smaller as the years roll on.

The post iPad Computing = Almost 100% 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.

Like I explained in the first two posts, one of the more useful ways of debugging web application problems is interrogating the DNS system, and the tool to do it is already on your computer: dig(1).

So, I was researching how Amazon’s ElastiCache works to debug a performance problem we were seeing. The caches were warming more slowly than expected, and we were seeing cache misses on data that we knew should be there.

Normally when configuring a Memcache client, you give it the addresses of every node in the cluster, and the client library figures out how to distribute the keys across those nodes. With an ElastiCache Memcache cluster, you configure the client library with one address—the configuration endpoint—and it dynamically adds and removes nodes from the clients’ configuration on-the-fly.

We configured the app with the endpoint URL, and it all seemed to be working fine. The app was able to talk to the configuration endpoint just like a normal Memcache server. But eventually we noticed the subtle problems listed above.

It turns out that the stock PHP Memcached module doesn’t do auto-discovery—for that, you have to install the AWS-provided module. But then why weren’t connections to the cache endpoint obviously failing?

As I was playing around with a small cluster, it seemed that using the config endpoint as a normal Memcache node worked just fine—it would store and retrieve entries as normal. So I looked at the DNS record for the endpoint:

$ dig -t any +noall +answer test-cluster.d00b1e.cfg.use1.cache.amazonaws.com
test-cluster.d00b1e.cfg.use1.cache.amazonaws.com. 15 IN A 172.31.x.y

The IP address was the same as one of the actual cache nodes, and the TTL was counting down from 15 seconds on successive lookups. Whenever the TTL reaches 0, the address changes to another one of the cache nodes:

So any given node can answer the special command to list the cache nodes, but if you connect a stock Memcache client library to the endpoint it will act like a normal Memcache server.

This behavior is surprising and doesn’t fit with a fail-fast design philosophy, but using the publicly available information at the heart of the Internet, we were able to figure it out quickly. The key is to know and use the tools at your disposal.

The post Digging Into`dig`: DNS Exploration appeared first on Software for Good.

In the last post introducing the dig(1) command, you’ll recall seeing an entry like this:

$ dig +noall +answer google.com
    google.com.		300	IN	A	216.58.216.238

Every DNS record has a similar format to this, and the fields are:

In this case, the answer says “The IPv4 address (A) of the domain name google.com. is 216.58.216.238, and you can cache that fact for the next five minutes.”

You can request other kinds of records with the -t option. For example, if you want to know, “What host do I connect to to send mail to someone with a gmail.com address?” you want the MX record(s):

$ dig -t mx +noall +answer gmail.com
gmail.com.      3599    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  10 alt1.gmail-smtp-in.l.google.com.

This says “Try gmail-smtp-in.l.google.com first (priority 5); if that doesn’t work, try these others in increasing priority order.” Or if you need to know what the authoritative nameservers (type NS) are for google.com.:

$ dig -t ns +noall +answer google.com
google.com.     21599   IN  NS  ns3.google.com.
google.com.     21599   IN  NS  ns2.google.com.
google.com.     21599   IN  NS  ns4.google.com.
google.com.     21599   IN  NS  ns1.google.com.

Authoritative who-what? This, combined with the TTL field, is where the “distributed database” part comes in: every domain has one authoritative nameserver (or at most a handful), which is the canonical data source for information about that domain. This is true not just of domain names that you or I would buy, but the so-called top-level domains (TLDs) as well. Ever wonder what the canonical nameserver for the .com. space is?

$ dig -t ns +noall +answer com
com.            13307   IN  NS  d.gtld-servers.net.
com.            13307   IN  NS  h.gtld-servers.net.
com.            13307   IN  NS  m.gtld-servers.net.
com.            13307   IN  NS  g.gtld-servers.net.
com.            13307   IN  NS  i.gtld-servers.net.
com.            13307   IN  NS  l.gtld-servers.net.
com.            13307   IN  NS  j.gtld-servers.net.
com.            13307   IN  NS  e.gtld-servers.net.
com.            13307   IN  NS  c.gtld-servers.net.
com.            13307   IN  NS  a.gtld-servers.net.
com.            13307   IN  NS  k.gtld-servers.net.
com.            13307   IN  NS  b.gtld-servers.net.
com.            13307   IN  NS  f.gtld-servers.net.

Those top-level name servers, operated by ICANN, don’t contain all the DNS records for every .com domain; rather, they delegate to the authoritative nameserver for a given domain.

But when you type google.com into your browser’s address bar, it doesn’t go to the authoritative nameserver every time. Your computer is configured to talk to a recursive resolver, which accepts DNS queries just like an authoritative nameserver but will follow the chain of lookups to find what the authoritative response is. It will then cache the result records according to their TTL, and the next time you look up the same address, it’ll just return it from its cache.

Try looking up google.com. again, and you’ll see the TTL decrease:

$ dig +noall +answer google.com
google.com.		232	IN	A	216.58.216.206

That’s your internet provider’s recursive resolver telling you, “Hey, I know this one (at least for the next four minutes). It’s 216.58.216.206.”

That’s how DNS works as a global distributed database: anyone can query it, there’s always one canonical source of a given record, and the results are cached by the server your users are querying. By now it should also be obvious that this is why DNS changes take time to propagate: the higher the TTL (a common value is 86400 seconds, or 1 day), the longer it will take for all of your site’s users to see the same records.

Up next: how I used this to debug a problem with AWS.

The post Digging Into`dig`: Get Your Hands Dirty appeared first on Software for Good.

You (person tasked with writing them and reviewing responses) know it. I (person tasked with reading them and responding) know it. RFPs (Request for Proposal, for those of you lucky enough not to know what this acronym means), are cumbersome, time consuming, and — in my opinion — an ineffective way to evaluate the most important aspects of a partner relationship.

So why do we keep writing and reviewing and reading and responding? 

I am always glad to hear from organizations interested in having us bid on a project. You think we might be a good fit for you? That’s great news! I would love to learn more about your organization and what you’re trying to do and figure out how Software for Good can help you get there. We know how important it is for you to find the right partner for a development project, because it’s equally important for us to find the right clients.

But then you hand me a 50-page document full of legal terminology and deadlines and forms and only one paragraph of real, helpful information about your project. With no mention of budget. And a tight deadline. And oh, can you do some spec work while you’re at it?

Cringe.

RFP-issuing organizations, I have some bad news for you: Instead of enthusiam over a potential opportunity, your RFP is most likely being met with frustration and reservation. Not to mention a host of questions: Do we actually have a shot at this? Is this project worth the amount of effort it requires to complete the RFP? And, most importantly, is this giant pile of confusing paperwork indicitive of the type of partnership we’ll have if we land this work?

Maybe not. But that lengthy, formulaic response you’re requesting might scare off a potential partner who would be an excellent fit for your needs. In fact, there are many agencies who refuse to respond to RFPs, and we’ve certainly considered it ourselves.

To be fair, I know a number of companies have no choice but to issue an RFP — many educational and civic organizations are legally required to compare bids. But for those of you who aren’t, here are four tips for finding the right agency without issuing an RFP:

Seek partners, not vendors
Many RFPs refer to development firms as “vendors.” While not technically wrong — we are, after all, selling a service — we always strive for partnership with our clients. To us, this means collaboration, mutual respect, and clients who hire us for our technical expertise, not our ability to crank out an application faster and cheaper than anyone else. A development partner will advise you, challenge your ideas when necessary, and work alongside you to achieve a successful end result. A vendor will do the minimum required to collect payment, even if what you’ve asked them to build isn’t in your best interest. Seek partners who have the insight and expertise to make your own ideas even better.

Make business personal
Open your door. Pick up your phone. Schedule a Google Hangout. Find a way to connect personally with the partners you’re considering before you ask them to submit a proposal. The role of chemistry in an agency/organization relationship is sorely undervalued in the RFP process. A quick meet and greet or phone call can be just as important to gauging the potential success of a relationship as a proposal. Our (your + my) time is valuable. We no more want to spend time crafting a proposal for a project we have no chance of getting than you want to spend time coming up with a way to diplomatically reject it. That’s a lot of work for two organizations without chemistry. Instead, let’s agree to shake hands and part amicably before anyone gets too invested.

Create space for new or different approaches
One of the most common reasons I’ve heard for issuing an RFP is the ability to easily compare agencies, proposed solutions, and cost. “If everyone answers the same questions in the same format, we can better evaluate them against one another.” Well, that’s a real creativity killer. We often struggle with how to best explain our approach or convey our ideas within the confines of an RFP format. Assuming that critical thinking and creative problem solving are integral to the success of your application, why not give your prospective partners the chance to show you what they’ve got? Try asking for proposals in whatever format an agency chooses vs. requiring them to respond in an Excel template. Not only will this give them the freedom to propose a custom solution, it gives you the opportunity to evaluate their creativity and clarity. The agency you choose should be in a league of its own — no comparisons needed.

Bring money to the table
Don’t be afraid to tell prospective partners your budget. When an RFP offers an opportunity for questions, we always ask for a budget (and rarely get one). But witholding that information is a disservice to everyone involved. A reputable development agency is not going to say “yep, it will take that exact amount!” in an effort to milk you for all you’re worth. Most likely, they will come back and say one of three things:

1. We can’t build what you’re asking for that budget, but we’d like to refer you to another agency that may be able to work within that range.
2. We think this is a much bigger project than what you’ve budgeted, but here’s what we can do for you with the amount you have earmarked for this effort.
3. Your budget is generous, and we think this can be developed for less. But we’ve provided a list of extra features you may want to consider if you have the funds available.

Being up front about your budget puts everyone in a better position — you’re not stuck reviewing proposals that come nowhere near what you’ve budgeted, and agencies aren’t investing significant effort into a proposal that has no chance of being accepted. Of course, you may not have a budget or any idea how much development will cost. If that’s the case, ask! Even if all the agency can do is throw out a “most of our projects start at $X” answer, that gives you a point of reference. If it’s too high, speak up. This probably isn’t the right partner for you, and that’s okay.

For some organizations, RFPs are and will continue to be the defacto method of partner selection. But for those of us with the freedom to opt out — well, let’s ditch the pages and pages of RFP busy work and focus on getting to know each other. Who we are and what we do doesn’t fit neatly into a spreadsheet. And if it did, would you really want to work with us?

Give your prospective partners the chance to wow you, and the right one will.

The post How to write a great RFP [Spoiler: Don’t] appeared first on Software for Good.

While debugging an issue with ElastiCache for the Star Tribune, I had a chance to use a public Internet research tool that not many people know about: The global DNS system.

Research tool? Yes, although most everyone thinks of DNS as a new-fangled form of Yellow Pages that slavishly translates memorable domain names like cuteoverload.com, dowebsitesneedtolookexactlythesameineverybrowser.com, and softwareforgood.com into their corresponding IP addresses, it’s actually quite a clever public, distributed database to which we all have access.

The command-line tools necessary to explore this database are probably already present on whatever computer you’re using, namely: dig(1). Here’s how to get started.

Let your fingers do the walking

Let’s do some basic DNS queries in a terminal, like your browser would do when you type in a URL:

 $ dig google.com

 ; <<>> DiG 9.8.3-P1 <<>> google.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38752
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;google.com. IN A

 ;; ANSWER SECTION:
 google.com. 266 IN A 216.58.216.206

 ;; Query time: 137 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Fri Jul 31 15:26:17 2015
 ;; MSG SIZE rcvd: 44

(Note there’s no apt-get install or brew install step there: dig comes pre-installed on OS X and most Linux distributions. Even on Windows, the similar nslookup tool is available in the command shell.)

There’s a lot of good detail there if you want to sort through it, but let’s focus in a little bit. dig has many querying and formatting options listed in its manpage, which lets you turn on and off various parts of the output shown above. To see only the IP address that gets returned, you can use +short, but I often want to see the entire answer line as shown above. For this, I turn off all the output except for that section:

    $ dig +noall +answer google.com
    google.com.		300	IN	A	216.58.216.238

That’s the basic usage, and enough information to get started. Next week I’ll explain what ‘300’, ‘IN’, and ‘A’ mean, and why they matter for your deployments.

The post Digging into`dig`: An Intro appeared first on Software for Good.

I mean, truly horrible. Like “Tips for keeping your emotions in check in the workplace!” horrible. Because you know how women are, we just can’t help but emote all over the place!

Around the same time, I started getting a complimentary (and wholly unwanted) subscription to a local professional women’s magazine. A glossy magazine delivered to my office with my name on it that splashed headlines like “Dressing for Success!” and “We Found It: The Best Mascara!” over glamour shots of successful local business women.

Can I tell you how excited I was for that to arrive at my place of business, where I was already fighting to convey my worth to an aging male superior who called me “kiddo” and asked me to take notes in every meeting where I was the only woman present?

I’d probably have 10 more stories like this to share if I thought a bit longer. The problem doesn’t just lie with this brand of gross, over-the-top marketing, however.

The real problem lies in the misguided belief that offering women-specific communications and events somehow supports gender equality.

Recently, the team at Software for Good had a discussion about the title of a event targeted toward women. I attended, and it was excellent. But our team’s reaction to the name was a collective “ick.” It wasn’t disrespectful, it wasn’t negative or sexist. It simply used a feminine prefix as part of the name, and it didn’t sit well with our team.

After some ruminating, I finally figured out why it bothered me so much:

An all-female lineup of speakers makes an event “female.” An all-male lineup of speakers makes an event…an event.

How likely do you think men are to attend an event with a female prefix? About as likely as they are to pick up a business magazine with mascara tips on the cover. Which is unfortunate, because men could learn a few things from the successful women of the world. Just as women could learn a few things from the successful men of the world.

Or, you know. People could learn a few things from the successful people of the world.

When it comes to women, why is professional development so often tied to gender? Why does a cover story touting the success of an intelligent businesswoman have to be tempered with beauty tips? And why can’t a technology conference featuring a lineup of female speakers be a technology event vs. a female technology event?

Gendered marketing isn’t doing us any favors. Here are three reasons why it harms our efforts to foster equality in the workplace:

1. Gendered marketing reinforces stereotypes.

I’m the only mother at Software for Good. That means I can’t make last-minute happy hours and most days I have to leave in time to pick up my children (Fun fact: schools and daycares require you to pick up your kids at the end of the day, even on days when the client is only available to meet at 5pm! Crazy, right?). Yes, this is the enormous difference between me and everyone else. Now where is my special lady magazine?

Having a family doesn’t keep me from doing my job. Sure, the needs of my children impede upon my work day at times, but so do my colleagues’ sick pets and car troubles and doctor’s appointments. You know, life. It happens, and there’s nothing gender-specific about it. But gender-based marketing suggests there must be something more to it. Why else would we need our own magazines and events? Women must need things that our male colleagues don’t know about, a super-secret list of special requirements necessary to our success. Something complicated requiring them to handle us with kid gloves, perhaps? And that sounds scary and time-consuming and like it might just cost the company a lot of money, so yikes. Better to avoid the ladies altogether, right?

You know what I need to be successful? Headphones and wifi.

2. Gendered marketing furthers the divide in male-dominated industries like tech.

If the only opportunities we have to talk about the issues we face as women are with other women, how can we expect change? We need to have these conversations among a broader audience, and labeling an event “female” ensures that will not happen. You know how many men showed up to the event I mentioned above? Less than ten by my count. Which is a real shame, because the women who presented were brilliant.

To be clear: I’m all for women organizing events or founding associations that center around mentorship and encourage young women to pursue careers in male-dominated industries like tech. But “women” has almost become an industry buzzword, a hot topic that every marketer feels the need to jump on, much like they did with social media a decade ago. If we talk about women in tech, people will think we care about equality! If we offer paid maternity leave, we’ll be considered forward-thinking! If we host an event for women, we’ll be doing our part to build a stronger, more inclusive industry!

The reality? Thoughtfully building a diverse team based on skill and shared passion shows you care about equality. Putting people-centric policies in place makes you forward-thinking. Creating opportunities for collaboration and communication among people of all backgrounds and levels of experience builds a stronger, more inclusive industry.

Stop talking about women to women. Start hiring women to work alongside men.

3. Gendered marketing limits learning…for everyone.

Know what I care about when it comes to my career? Growth. Efficiency. Productivity. Results. Development. Change. Innovation. Teamwork. Culture. Know what my male colleagues care about? The same. Not a single presenter at the event I referenced talked about fashion or motherhood. They talked about securing funding, building teams, getting publicity, exit strategies. Already this week I’ve had multiple opportunities to share their wisdom with my male colleagues. I wish they’d been there. But here’s the conversation that took place among my coworkers in Slack a week before the event:

Male Colleague 1: “Is this only for women?”
Male Colleague 2: “Is what?”
Male Colleague 1: “The [event name] thing.”
Male Colleague 2: “Yeah, I think it’s mainly for women to attend but they aren’t going to turn men away.”
Female Colleague: “You should go if you are interested in it. The speaker list is really great.”

I think he would have attended if tickets hadn’t been sold out, so I give Anonymous Male Colleague 1 credit for that. But the name of the event made the males in our organization feel as though there was nothing there for them. A missed opportunity, for sure.

So, what do we do?

Sure, we can (and should) stop gendered marketing. But there’s no cure-all, no single fix that addresses the issue of gender equality in tech or any other industry. There’s only progress. Small steps by organizations and individuals who are bold enough to do things differently.

Women who are willing to say “I don’t need this. I don’t want this. And here’s why.”

Men who are willing to say “Why is this only for women? What does that mean? Tell me more. I want to understand.”

Organizations that are willing to say “I see your talent. I’m going to fairly compensate you for it. And I’m going to expect great things from you.”

Industries that are willing to say “Let’s invite marginalized groups to share their experiences, listen to what they have to say, and work toward change as a team.”

Women don’t want special magazines or lady events or to be treated with kid gloves. We want the respect of our peers and the confidence of our employers.

Let’s do better. Together.

The post How Not to Cry at Work, or Why Marketers Keep Getting it Wrong When it Comes to Women appeared first on Software for Good.