Mapmaker, Mapmaker, Map Me a (Google) Map

A picture of google maps with the search field saying Jane stop this crazy thing

So you want to embed Google Maps in your website. Maybe you have a list of locations you want to display, or perhaps you need to provide directions or perform simple GIS operations. You’re a pragmatic person, so you don’t want to reinvent the wheel.  You’ve settled on Google Maps as your mapping platform, acquired your API key, and you’re raring to go. Awesome! I’m so excited! Google Maps has great bang for the buck, and their API is well documented and easy enough to use.  But there’s a downside. Google Maps has become the Power Point of cartography.

But all that’s just fine, because we can still do some great work with this tool. I’ve written some general tips that I’ve learned after making a few of those “Contact Us” and “Locations” pages you see, but they are far from prescriptive. You, dear reader, are the adult in the room. All of these tips should be taken with a grain of salt.

I’ve written this article from the perspective of someone who is familiar with Javascript and DOM events, but I also hope it will raise important questions and gotchas for people who still want to have great maps and have chosen Google. This article should take about five minutes to read. Let’s get started!

You have options. Specifically, you have MapOptions.

Even a cursory glance over the documentation for MapOptions will be worth your time.  This is Google Map’s “Look what I can do!” section.  Want a simple map without all the UI bureaucracy?  Oh look, disableDefaultUI right there! How nice!  Most UX and UI tweaks can be done with a careful and considered use of MapOptions. Experiment with a variety of configurations.

Own your map. Own your Style.

Various styled and colorized maps juxtaposed with Andy Warhol's classic screen printing of Marilyn Monroe.

Google Maps v3 has Styled Maps. For a crash course, take a quick jaunt over to SnazzyMaps to get some inspiration. Note how their own map style reinforces their brand.  If you really wanna get your hands dirty, though, you’ll have to learn Google’s Styled Maps from the ground up. The results are worth it. For the extra mile, you can style Map Markers and Info Boxes too. Be sure to check Google’s Styled Map Wizard.  You can also head over to Stadtwerk.org’s Styled Map Colorizr. Don’t forget your color theory!

Remove irrelevant labels.

A simple comparison of a map with and without labels.

If your labels compete with the data, get rid of them or find a way to quiet them. Do your users need to be told where the North Atlantic Ocean is?  Do you need to know the province names AND the city names? This isn’t to say that all labels should be removed, but hiding extraneous information will give your data more elbow room.  Don’t make your map be all things to all people; make it the right thing for your people.

Stay on topic; constrain the view.

Hi.  I have ADD. If a content manager takes about three hours to enter in the geo locations of all 52 of artisan waffle shops onto a map of North America, you can bet within 10 seconds I’ll have already left the confines of North America and centered my map on Ouagadougou because OOH BUTTERFLIES!

Stay on topic and stay the course.  Reducing scope also helps you focus your own optimization efforts. You’ll enjoy a reduced workload, and your user will enjoy an increased attention span.

Consider setting minimum and maximum zoom in the MapOptions object.  As far as constraining the viewport, you may have to write some custom code to stay on topic. If users need to view a particular location up close, it’s very easy to provide an external link to maps.google.com.

Consider Clusters for large amounts of Map Markers.

MarkerVsCluster

https://developers.google.com/maps/articles/toomanymarkers

Watch out for UX Gotchas!

Avoid full bleed on mobile devices, as user may be unable to scroll. Give small gutters on either side to give enough affordance to scroll freely.

Imagine a long blog post (like this one) where there was a map near the bottom. A smartphone user scrolls down, dragging their finger across the glass. Eventually the large map scrolls into view, and the scrolling momentum takes the map entirely into their view.  The user intends to skip this content and continue scrolling down. They use the same action – they have no choice. GOTCHA! Instead of scrolling the document, the map captures the event and pans the map. If the map takes up the entire viewport, the user is effectively trapped. What an awful thing to happen! On mobile, be very very careful with maps. Your users will reach Antarctica before they reach the footer.

A similar case can happen with mouse scrolling on desktops. Turning off zoom in the API prevents scroll event captures, which can be frustrating.  Add a zoom control if your design calls for it, but consider disabling scroll-to-zoom events.  Again, pay attention to MapOptions.

Maps are for everyone. Support Localization.

2014-02-02_1710-2

Google has a wide range of supported languages for its map API, but you may need to tweak your javascript tags to enable them.  Not only are labels properly localized, but so are controls and even the routing directions.  If you support internationalized content, this little tweak is definitely worth your time. 

There is life outside of Google Maps.

Mercator projection comparing supposed size of Greenland against Size of the continent of Africa

Google Maps is an excellent tool, but it may not always be the right tool for the job. Ask yourself what it is you want to show. Scale matters. If you want to show people how to get to your locations, then Google Maps is often an appropriate tool.  If you want to show that you have an international presence, then Google Maps’ default Web Mercator projection may not be… politically correct.

Without falling too deep into the cartography projection rabbit hole, do consider using Winkel Tripel or Robinson projections instead of Web Mercator when your data is presented at the global level.  These projections hew closer to the way the world actually looks – note the size of greenland compared to the continent of Africa.  However, Google Maps Javascript API v3 is strongly oriented around Web Mercator.

Let’s not be too hard on Google Maps. It’s a round planet. Your monitor is flat. The math dictates that something has to give here.  Suffice to say that the eternal battle of Conformal projections against Equal Area projections may seem a bit academic to people who just wanna know how to get to Denny’s.

If you love data, but you hate Mercator projections like I do, then may I suggest that these problems may require you to consider tools outside of Google Map? Because I just did. Technologies such as D3.js, Open Layers, and GIS software may need to be employed. But then you can be the coolest kid at the party.

Comment

The Art of Remote Communication: “Say that again?” “Garble goble jibble plurb. ”

 

The Scenario

Maybe you have had a similar dream that goes something like this… You have a very important meeting ahead of you. You are about to meet a brand new client and you’ve practiced your pitch to a tee. Your mind has been racing for hours if not days and your meeting objectives have been looping in your head. Naturally you want to do great and you want the meeting to be a success. A lot is at stake and you don’t want to mess up. Instead it turns out more like this…

You walk into the room of executives, you shake hands with them but none of them make eye contact with you and some even ignore you. Some don’t even notice you at all and others stare at you uncomfortably. You look for your teammates for help and assurance but they don’t notice you at all either. Next, the meeting starts and it’s your turn to speak. You move your mouth but no words come out. You become more and more uncomfortable, you start to sweat and even panic. You’ve missed your chance to speak and the meeting moves on. You didn’t get to contribute and even worse you fear that you’ve made an awful impression on the client and your peers. You did. You wake up panicked and infuriated. Thankfully it was just a dream.

Only this is not a dream but a reality of what a typical remote meeting can be like for you. You walk in into the meeting with a focus on the agenda only to find that you get taken off course by technical and engagement difficulties. Common occurrences like video disruptions, microphone echoes, and phone static all come in the way of effective and natural conversation. This can make remote participants feel invisible and awkward at best. It’s easy to feel disconnected and left out without the physical presence of the room and the people in it.

Unfortunately that is the reality more often than not. If your job is for the most part not task-execution focused in nature you will have to make up for the lack of rich human interaction that happens naturally between people who share a physical location. Digital tools such as video conferencing, IMs and constant emailing filter the rich human qualities that are critical in fields like UX, where the success and quality of a project is driven on collaboration and frequent brainstorming.

Know the Limitations of Digital Communication Tools

Armed with talented WFH (work from home) staff and distributed offices we – at The Nerdery –  work remotely a lotH and here are a few takeaways from our experiences. We give technologies (eg. Google hangout, Skype, jabber) too much credit. In theory you would expect to hop on Google Hangout or Skype and to have a near flawless, normal human interaction. That is an ideal user expectation which at this point in time – from our experience – is still a theory. We like to believe that currently-used remote communication methods are as reliable as we expect them to be, but be prepared to deal with common issues. Video interruptions, audio cutting out, microphone feedback and echoing, and loss of visual are all the little things that will ultimately throw you off and limit your effectiveness.

An unavoidable side effect of remote meetings (formal and informal) is miscommunication, which ranges anywhere from mishearing or not hearing at all what is said, to not seeing people in the room causing inability to pick up nonverbal body language. Some people are very verbal whereas others understand the world more by observing and perceiving their environment. For those people, collaborating and running meetings remotely is excruciatingly painful as the essence of the environment is filtered through the digital tool. It becomes essential to have a game plan when working remotely.

Implement a Strategy to Increase Efficiency and Effectiveness

Anticipating issues and implementing strategies is winning half the battle when it comes to remote communication. The first rule is to set expectations early on with both your team and/or the client. If there is not an established standard at your company when it comes to remote interactions, create your own set of expectations based on what has worked for you and share it with your team. The list should include essentials of what you need to be effective in order for the project to be a success. This can include meeting five minutes before a meeting to ensure all tech is working properly and to go over the agenda.

Another example would be to call in after a client meeting to debrief as a lot of conversations happen “offline” and if you are working remotely it is critical that you create opportunities to be part of informal post meetings. What works is to schedule an internal, post-meeting 5-10 minute debrief. There is still no effective way to make up for the spontaneous conversations that happen naturally, so to ensure that you are not disconnected from what is going on, ask the project manager or lead for recaps or status updates that are made available first thing in the AM and or PM. Depending on the project those may happen once daily or a few times per week but it is essential that they do.

In Summary

Remote clients, distributed teams, and remote offices are here to stay. Communicating remotely at this point in time is not perfect but it is essential and should be embraced.

Hopefully in the near future technology will advance enough to allow remote participants to have a more rich remote presence that will not strip us of our human essence. In the meantime it is essential for any company to have standards in place and an etiquette that strives to have better remote communication best practices. It is imperative to have a set of ground rules to work from that will make up for the lack of rich communication between distributed (non-collocated, remote) teams.

Stay tuned for a series of follow up posts where practical remote communication techniques and tools will be presented in more detail.

Comment

Filed under Articles, The UX Files

True Romance at the Overnight Website Challenge

You can’t make up a how-we-met story quite like the romantic Web Challenge tale of Angie Sheldon and Reed Enger – a happy couple who returned to the Web Challenge last weekend as guests of honor to relive their memories of meeting-cute three years ago at our pre-Challenge needy-meets-nerdy speed-dating mixer – and getting paired-up from thereon.

 

Comment

For security’s sake update WordPress to version 3.8.2

On April 8, 2014 WordPress released a security update to version 3.8.2. The announcement that accompanied the release states “this is an important security release for all previous versions and we strongly encourage you to update your sites immediately.”

WP 3.8.2 addresses two potentially serious security vulnerabilities, includes three security hardening changes, and addresses nine “other bugs.” Most notably the following security issues are addressed:

  • Potential authentication cookie forgery. CVE-2014-0166. (Very serious vulnerability!)
  • Privilege escalation: prevent contributors from publishing posts. CVE-2014-0165.

  • Pass along additional information when processing pingbacks to help hosts identify potentially abusive requests.

  • Fix a low-impact SQL injection by trusted users.

  • Prevent possible cross-domain scripting through Plupload, the third-party library WordPress uses for uploading files.

Additionally: JetPack – the wordpress.com feature-rich plugin suite – was updated to version 2.9.3 to address similar issues.

If your site is currently operating a WordPress version below 3.8.2 or Jetpack version below 2.9.3, you may be at risk and should consider upgrading as soon as possible. 

Comment

Filed under Tech News, Technology

The Evolving Technology of Social Media

This webinar explores the technology behind the tools businesses and community managers are integrating into their software platforms. This is not a discussion about which key words resonate best with an audience or optimal word counts. Nerdery developers and social media integration specialists Thomas McMahon and Doug Linsmeyer  describe the software options typically leveraged on social media software integrations. Our audience gave feedback that anybody could follow this conversation, regardless of their technical level. Social media consultants, account managers, and anybody seeking an understanding of the tools and technology going into today’s social media integrations will find this discussion useful.

Slide Deck: To view the slide deck you can visit our Slideshare page.

Bonus Q&A Podcast: (running time 9:22)

Our panel of experts follow-up with three of the  interesting questions from our live audience that we didn’t have time to address during the webinar:

  • Are location-aware tools like FourSquare still worth considering?
  • Possible technology solutions to promote a mobile business.
  • The different social platforms and how they differentiate, and more.
Play

Comment

Heartbleed bug security alert: Your web server/data may be vulnerable – test your domains

On Monday evening, a security firm announced a new vulnerability in a key internet technology that can result in the disclosure of user passwords. This vulnerability is widespread and affects more than two-thirds of the web servers on the planet including top-tier sites like Yahoo and Amazon. If you have a secure (https) website hosted on a Linux/Unix servers using Apache or Nginx or any other service using OpenSSL, you are likely vulnerable.

For a detailed breakdown of this vulnerability, please see this site. This security vulnerability may affect up to two-thirds of all web servers. We urge you to assess your vulnerability immediately, and reach out for help.

How can I get help to fix this problem?

How can I see if my servers are vulnerable?

You can use this site to test your domains for the vulnerability. Enter the domain of your HTTPS web site. If you get a red positive result, you are vulnerable.

In addition, you can execute the following command on your servers to see if they are running a vulnerable version of OpenSSL: openssl version -a

If the version returned is 1.0.1, and its build date is before April 7th, 2014, you are vulnerable.

How can I fix it if I am vulnerable?

You will need to obtain a patched version of OpenSSL and install it on all vulnerable servers. Updated packages should be available for Debian, RedHat, Ubuntu, and CentOS via their package managers. If a package is not available for your platform, you can recompile the OpenSSL package (version 1.0.1g) with the NO_HEARTBEAT flag, which will disable this vulnerability. After updating, restart any services that are using SSL and re-test your domain using the link above (http://filippo.io/Heartbleed/).

For information on your specific Linux distribution see:

Additionally, you should strongly consider changing passwords and/or resetting SSL certificates, but only after OpenSSL has been updated.

What is the vulnerability?

With the vulnerability, called Heartbleed, attackers can obtain sensitive information from servers running certain versions of OpenSSL. Examples of sensitive information include private encryption keys for SSL certificates, usernames/passwords, SSH private keys on those servers and more. Attackers which obtain the keys to your SSL certificates can then set up a man-in-the-middle attack between you and your customers and obtain secure information, such as credit card numbers and authentication credentials. The vulnerability was publicly disclosed Monday, 4/7/2014.

If you have any questions, please contact us, or ping your own go-to Nerdery contact right away. We’ll help analyze your risk and protect your data. If The Nerdery can be a resource to you in any way, we will.

Comment

Filed under Tech News, Technology

Dashicons Make Your WordPress Dashboard Cooler

What Are Dashicons

On December 1, 2013, WordPress 3.8 – code name “Parker” – was released. One of the highlights of 3.8 was the re-skin of the WordPress admin, officially called the Dashboard. The re-skin got rid of the blue, grey, and gradient interface for a more modern and flat design. Included in the update were Dashicons, an icon font.

An icon font has all the benefits of being text and none of the downsides of being an image. Size, color, and pretty much anything else you can do with CSS can be applied to icon fonts.

There are several ways to use Dashicons inside the Dashboard. For this example I’ll be using a plugin, but you don’t have to. If you’re more of a functions.php person, it will work there too. I’ll also be skipping over the details of customizing WordPress and focus on Dashicon-specific code.

Set Up Base Plugin

I already have the plugin created, uploaded, and activated. You can see the final plugin on Github. For each section, I’ll only be highlighting the relevant code. The code could be included in your own plugin or the functions.php file by using the appropriate hooks and filters.

Read more

Comment

Filed under Technology

Software maintenance = strategically-planned evolution

Thinking of starting a maintenance program? Picking the right number of hours can make a big difference as to how your project works.

I’ve done a number of maintenance programs and each one is a little different, however they fall into one of three buckets; no hours, few hours, lots of hours.

If you choose to do no hours, meaning you just call out of the blue when you want work done, or if you have very few hours, the main disadvantages you have are knowledge, developers, and timeline.

Ideally, one developer would be on your project to help with all future fixes. Having a developer with background on the project, code, and client relationship is beneficial. However, those developers are valuable. They will get put on another project if they aren’t busy and they will become unavailable for yours.

When you lose the developer, you also lose some of the knowledge. We’re still a team and still transfer knowledge form one developer to the next, but switching developers can reduce some efficiencies. We all do our best, but the new developer still has to learn all the ins-and-outs of the code.

And then there is timeline. If we can’t plan for your maintenance changes, you will have to wait until a developer becomes available. That could be a few days to a few weeks. It all depends on developer availability and the complexity of the changes.

Now, if you have a good amount of hours in your maintenance bucket, it’s easier to keep a developer on the project, retain knowledge, and plan for the work.

I’ve been working with one client for about three years now and I continue to lead the maintenance project, which is supporting the sites that we created. Every time they ask for something I know the project history,  I know what we’re talking about, and I know which developers actually built individual pieces of the site. Knowing all this makes it much easier to understand the request, estimate, and execute.

This client also has a good bucket of hours, which helps me plan for changes. I know that – based on the client budget per month – I need to spend x hours per week. Not only does this help me plan for development, but it also helps with setting expectations for the client. Our turnaround time on requests is usually a few days. We’ve gotten ourselves into a groove and it works well for the client and The Nerdery team.

What’s a good number of hours?

That’s a good question. How many changes do you plan on having? Do you think you’ll have some minor changes and updates? Or do you think you have some features you’d like developed during your maintenance program? Are you thinking of a handful of changes per month or do you have a long list already and it just keeps growing? It all depends on how much work you want done each month and how fast you want to get things completed.

For example, if you’re thinking 40 hours a month, one developer can plan for about six hours per week. Now, when other projects come up, that developer can safely plan for both projects. However, six hours per week also limits the amount of work the developer can get completed. More complex tasks may take a few weeks to complete.

Wait, six hours per week is only 24 hours a month. What about the other 16?

Another thing to consider when setting up maintenance hours is that the hours are not all development hours. You have to have some time for project management and QA. There will be phone calls, and email communications, status reports, and we’ll want to run any change through QA to help ensure we didn’t fix one thing and break another.

Quite often people think that maintenance is just finding and fixing bugs, but it’s more than that. It’s also about keeping things updated, about enhancing existing features, and it’s about building out new features. It’s about ensuring your site/software continues to evolve and grow instead of just standing still. In technology, you’re either getting better or you’re falling behind. Standing still isn’t an option.

Comment

Filed under Technology

The Balancing Act of Respecting Users While Maintaining a Minimum Viable Product

“The software isn’t finished until the last user is dead.”

 –Anonymous Support Group Member

The user

While the sentiment isn’t perfect, I find this short, 10-word quote explains the goal of ongoing product development. The key word here is “user.” If the product owner, business owner or executive is not thinking about the user, and their need to constantly improve the user experience, they may want to reconsider what problem the software, app or product is trying to solve in the first place.

While there are many things that can contribute to what needs to be updated or changed within an application, listening to the users is one of the best ways to get feedback before making educated decisions about what needs to be improved to address their concerns.

People use technology and software to make their lives easier; if the technology does not make the job easier, they will quickly find another solution. If users are forced to use a certain product and find it frustrating, they will eventually give up or call into customer service and request to talk to a real person, which defeats the goals and efficiencies of creating something in the first place.

Is your application green and growing, or is it withering and dying?

If it’s green and growing, you need to constantly be looking for ways to make it better and keep it growing, and constantly be working on feature enhancements and bug fixes, and roll these changes out in a timely manner, or consider rolling them out as part of a monthly or quarterly release.

If it’s withering and dying, you need to start planning for a replacement, or decide at what point the user will no longer be supported.

The Software

While everyone wants the software to be perfect and that they have every feature implemented when presenting it to the world, that’s not practical; at some point some tough decisions need to be made about what is going to be included in the first release and what features need to be added to the backlog of items they want to add in future releases.  However, many of the items that are in the backlog when the product is released will be reprioritized; some of these items will never be implemented at all because new and more important items will take their place.

Some  suggest that the first release should be 90% complete, and that 10% should be implemented after the initial release; others suggest that it is 70/30. The simple truth is there is no magical formula when trying to define when and what should be included in the minimum viable product (MVP) release and what should be included in future releases.

If you plan your budget around making some minor changes after MVP release, and there is an outcry from the users about all things they suggest or would like added or changed, you will quickly burn through your budget. Or you could release your MVP light on features because you plan on adding other features and enhancements later, and users could complain that you missed the mark and may not want to wait for features to be released someday.

Every business, industry, budget and application is different, and you need to consider many things when making this decision. As you could probably can guess from the opening quote I like so much, I am an advocate of ongoing enhancements, and I am a firm believer that good software is constantly evolving and is an ongoing improvement process.

While your software, app or product is not going to last forever, it does need to keep evolving and improving, or it’s going to quickly become obsolete before its time.

Comment

Filed under Articles

Pre-Web Challenge advice for nerds & nonprofits

New-and-improved, “What to expect when expecting to be at The Nerdery Overnight Website Challenge.” Over the years we’ve culled quite a bit of advice from web pros, nonprofits, and our own nerds alike. Every year, in an effort to help you be as prepared as possible for the 24-hour nerd-a-thon, we update this post and share it with you.

Are you a webchallenge vet? Leave your helpful hints in the comments and we’ll add them to this list for next time!

Advice for web pros

Come prepared

  • Get your critical thinking tasks done as early in the game as possible.
  • Assess risks as early as possible, too. You don’t want to be solving challenging problems at 4 AM.
  • Work in small bursts. Attack something concrete for 30-60 minutes. Accomplish it. Take a 10-minute break.

Designate roles now
Designate a person who can respect everyone’s opinions and can diplomatically make tough choices when there are differences of opinion. Democracy and waiting for consensus don’t work well on short timelines. Choose the one person who you can all be angry at. Ideally, this would be your producer or your team lead. Other roles to designate:

  • Server / connectivity / tech support
  • Database guru
  • Source control and backup master
  • Back-end CMS team
  • Front-end html/css integration team
  • Flash / jquery / front end dev
  • Design team
  • Writing / content plan
  • ia / wire-frames
  • Producer
  • Sweeper
  • Special ops

Get your tools in order

  • Choose your tools – server environment, dev language, frameworks, CMS, plugins, etc.
  • Staying in sync with your team is critical. Consider what IM everyone will use, and email addresses. Share a list with everyone or create a mailing list. Come prepared with a platform to work on, be it a CMS or framework, and work out dev server logistics, passwords, svn/git users for all your team members.
  • Go with what you know. Also, from one of our nerds: Our team made use of Nerdery’s Google Docs for info/collaboration last year, same with svn. Point is, you do this stuff every day, rely on your proven workflow and tools.
  • Research what you don’t know. You don’t want to be figuring too much out the night of the challenge.
  • Have an expert on your team for anything you’re choosing to use.

Have a backup plan. If that new CMS you wanted to use doesn’t work out the way you were planning, be prepared to fall back on that clumsy solution you know like the back of your hand. Be prepared to make this hard decision within a few hours of starting.

Be connected

  • Determine if everyone is using their own sandbox on their computer or a central server. If using a server, set it up before you get to the webchallenge.
  • Get everything you plan to use running.
  • Make sure everyone will be able to connect to it.
  • Test / simulate if possible.

You DO NOT want to spend the first three hours of the challenge sorting through connectivity issues, getting passwords, and figuring out how to turn off php magic-quotes and get mod-rewrite working correctly in order to get your CMS running.

Back it up

  • Use source control. Or, have a really good plan for making snapshot backups.
  • Have one or two people on the team make local backups at key checkpoints.
  • Count on someone trashing the wrong folder and deleting four hours of work at 6AM – that someone will probably be you.

Plan your attack

  • Get the whole team together for the first hour to discuss your plan with the client.
  • Make sure you understand their audience(s) before you begin anything else.
  • Make a site map. The client will hopefully bring their ideas to get the discussion started.
  • Content audit – understand what needs to be written, what images need to be obtained, where to source content for each section of the site map.
  • Spend time wireframing.
  • Get hosting figured out right away, get all their credentials in one place: social media logins, domain registrar info, etc. Assign someone to own this information with the non-profit.

Listen to your client. Stand with what you believe is the right solution, but if you disagree on something in these early stages, don’t be afraid to listen some more. It’s worth the time. Remember that you both want to make the best site possible. Also, LIMIT THE SCOPE! You won’t get as much done as you want. Most non-profits will shoot for the moon and be scattered on their priorities. Help them get there but also help them remain realistic on expectations for what can be accomplished.

Outside of the standard CMS and site dev, plan on tackling only 1 or 2 custom features that address a core business objective.

  • Have one owner per custom feature. This is your special ops people (person).
  • Failure or difficulty here should not jeopardize the rest of the project.

The Presentation

  • Start work on your presentation right away.
  • Assign a presenter.
  • This is a joint effort between the team presenter and the client.
  • Your presentation starts when you begin planning. The output of your planning session should be an outline for what you want to accomplish. You want to present that the next day as an outline of what you  did accomplish.
  • Do not start preparing this at six in the morning. You will have the effective IQ of a can of V8. Nobody cares about what tomato and celery have to say.

Advice for nonprofits

Come prepared

  • You know your business better than anyone else, the better you can communicate this to your team the more effective your site will be.
  • The faster you can transfer this knowledge, the more time your team gets to work on making things to solve your problem.

Delegate expertise

  • Your team knows design, understands user experience, and has experience making successful sites.
  • Send an expert that can represent and communicate your organization’s’s mission, brand, and message.
  • Allow your team to choose the tools they believe will best enable them to solve your organization’s problem.

Understand your objectives

  • What does your website need to accomplish? What’s your goal? What would a successful site look like / what role would it perform? Who does your site need to talk to? Clients? Donors? Volunteers? The Public? Staff?
  • Rank those audiences in order of their importance with respect to the site. Who does the site need to serve: Volunteers, Clients, and then Donors or Clients, Donors, and then Volunteers. This is hard, but you need to make a decision here.
  • For each audience, what does the site need to do for them? Why do they come to your site? What do they want to accomplish when they get there? What do you want to entice them to do?

Make a sitemap

  • You can do this on a whiteboard or with post-its.
  • Make a page for each piece of content that you can think of: home page, how to volunteer, about us, staff, location map, what we do, etc.
  • Make sure you have accommodated the content that is essential to your primary audiences.
  • Organize these pages into groups, sometimes it helps to start first by grouping by audience. Also try grouping it by subject matter.

Try to keep the site from being more than three levels deep. Then aim to organize things at a max of two levels deep. Can you take it to one level? Find the balance between organization and the ease with which users can find your content.

Plan your content

  • Does a page include photos?
  • Other than just a few paragraphs of text, are there other relevant data types to think about? Dates, youtube videos, inventory, links to other pages.
  • Special pages to consider with specific logic and data: job postings, events, press releases, blogs, etc.

Find your content

  • Plan on bringing everything to the event that might be edited and incorporated into the final site.
  • Any content, images, or copy that isn’t brought to the event ready-to-go and awesome will need to be produced and written before it can be edited and incorporated into the site. Is this where you want your team to be spending their time?
  • You might be lucky and have a word-smith on your team. It’s also possible that you’ll end up with programmers writing your homepage copy. Think about that.
  • Images. Photography. Big. Beautiful. Personal. Bring them.
  • Logos, and brand assets. Vector format, if possible.

Plan on participating

  • You should expect to be a major contributor to your team.
  • Your contribution will make the work better.
  • A joint effort will be a huge motivator for all team members. At 5 AM you don’t want any team members feeling like slave labor. Your skin in the game will prevent that from happening.
  • Again, you have unique and special knowledge about your organization that can only make the work more relevant.

Advice from the Judging Corner

  • Listen, listen, listen to your nonprofit’s needs and objectives. The more your site’s features can reflect what your nonprofit is asking for, the better.
  • The judging begins during the last hours of the 24-hour window. No, your site doesn’t have to be 100% done for the presentation, but it should be at a place where you can demo something.
  • Focus on your site, not your presentation. The judges love seeing your site. Not your Powerpoint. Demo > Powerpoint. Seriously.
  • Be sure to demo both the user experience and admin functions. If you’ve added custom admin features to your CMS, be sure to demo them. The judges want to know that the nonprofit can manage this site on their own.
  • +1 to the Limit Your Scope advice. Judges are impressed with scope that can realistically be accomplished in 24 hours.
  • Did I mention demo? Yeah, be ready to demo. Make sure you’ve got some functional site features. Enter content on key landing pages. QA your key functions. Solid demo = judge love.

Winning: Four awards result from from the judges’ scoring: Design and User Experience; Functionality; Impact; Best in Show. Scores on Design/UX , Functionality and Impact make up three-fourths of the Best in Show Award, which also includes one final important element: Launch. Teams who’ve launched* by Web Challenge Awards day will receive full marks in that category. Please be done; you’ll be rewarded. Separately, a People Choice Award will be publicly-tallied on Facebook. At Awards Night, we could have five different winners, or it could be a clean sweep.

*Your site will be considered launched even if full deployment is delayed by things outside your control (e.g., delayed content entry by the nonprofit or delayed sign off from the nonprofit’s stakeholders or leadership). If a site has not been deployed for reasons beyond the development teams’ control, a URL to a staging site can earn launch points.

Judges will base their scores on four things: An in-person conversation with each group at the event; a written statement about the site from the team; a written statement about the site from the nonprofit; review of either a working URL or page mockups provided by the team.

Advice for All Attendees

  • Bring slippers and sweatpants! Who wants to be wearing jeans at 3am?
  • Load up on Free Buzz Aeropress, regular or iced.
  • Drink lots of water and remember that at 3AM you might not be as productive as you wish you were, and that’s okay. Patience is key. Try to relax, enjoy it, and be satisfied with whatever you’re able to accomplish.
  • Bananas help keep you awake and focused. True story.
  • Plan a ride home afterward. You don’t want to drive after being up that long.
  • Bring a toothbrush and deodorant, so you can get all prim and proper prior to our presentation.
  • Bring Chapstick, Burt’s Bees, or whatever your lip balm of choice is. Trust us, you’ll be happy you did.
  • There will be a “crash room,” lights out and quiet. It will have two twin-sized air mattresses up for grabs, or you can curl up on the floor. Some nerds are bringing sleeping bags (others choose to curl up in the entrails of a ton-ton).

Nine out of ten nonprofits who’ve experienced this annual 24-hour event will tell you they won the lottery – and that their team of volunteers was the best of the bunch. And we’re doing everything we can to raise this success rate.  With input from past participants combined with our own experience as event organizers, we endeavor to set teams and their nonprofits up for a successful slumber-less party.

Nonprofits selected are not guaranteed a new website – one that launches without a hitch, 24 hours after meeting their team. This rare opportunity is just that: an opportunity for nonprofits to have 8-10 interactive professionals at their disposal for 24 hours. Were the meter running for a typical team, their fee would range in neighborhoods near $20,000-$30,000. Instead, volunteers are motivated by friendly competition and geeky goodness.

In an effort to form more perfect unions, we ask applicants – nerds and nonprofits – to agree to a social contract, and to each their own pledge:

Nerds: If my team is selected, I’ll do my best to deliver a good outcome for whatever nonprofit we are assigned to serve. If my team feels our designated nonprofit is asking for more than we can reasonably accomplish in 24 hours, we’ll adjust their expectations – and our scope of work – accordingly. My team will involve our nonprofit in key development and design decisions en route to delivering an interactive product that will further their mission and online presence. I will honor my team’s stated and agreed-upon commitment of ongoing support for our nonprofit.

Nonprofits: If my nonprofit is selected, I’ll treat my volunteer team with due respect during and after the Challenge, knowing that they’ve similarly pledged to do their best to deliver a good outcome for us. If my team of volunteers feels that we, as their designated nonprofit, are asking for more than they can reasonably accomplish in 24 hours, we’ll limit our expectations – and their scope of work – accordingly. I will provide collaborative input into key development and design decisions en route to creating an interactive product that will further our mission and online presence. I will honor my team’s stated and agreed-upon commitment of ongoing support for our nonprofit.

All together now, Kumbaya – in the key of Hard Day’s Night. All who enter into this do so with the very best of intentions. When people invest their time and talent toward a common cause, it’s incredibly gratifying to see it all come together, and ultimately, make a difference in the community. But you can’t just fill a blender with nerds and nonprofits, hit puree and expect a delicious smoothie, every time. In the end, the surprise isn’t that sometimes participants don’t spark a needy-nerdy love connection, but how overwhelmingly often they do.

We do not require that teams make a commitment statement of post-event support. We provide a framework for service, if teams want to take that and adopt a nonprofit as a long-term service project, that door is open. We’re not trying to shape a team’s service – we provide the opportunity for teams to do that for themselves. Having a team draw up a scope-of-work as part of their initial discovery hours is a great idea. We’d much rather that every team have a small scope-of-work that they can reasonably complete in 24 hours. We actually tell that to teams. A lot.

Since The Nerdery Overnight Website Challenge began in 2008, volunteers from throughout the interactive community have freely given millions of dollars worth of professional services to nonprofits. The late great Luke Bucklin would probably still call this just a good start. Right again. This science experiment of mixing needy with nerdy is working, but it’s forever a work in progress.

Advice from The Hooded Do-Gooders.

Comment