The Math Working Group has published two W3C Recommendations today:
Learn more about the Math Activity.
]]>
Quick Left of Boulder, Colo., hosted developers, designers and tech enthusiasts in January for a beerfest hackfest. During the three-hour hackfest, teams were tasked with designing beer-themed apps. One of the hacks was Beervision, which enabled users to take a photo of a beer that the app paired with a song based on the look of the beer. (Photo courtesy of 23rdstudios|Paul Talbot)
Problem solving is in Dan Mandle’s blood.
Years ago, Mandle converted a 2004 Volkswagen Golf from diesel to run on vegetable oil.
Today, the 26-year-old interactive developer for Movement Strategy in Boulder, Colo., downplays his work on the vegetable-oil-fueled VW but proudly cites the perks of such a solution.
“I got used vegetable oil from the university’s food services department and drove the car for free,” he says.
For Mandle, innovation is one of the reasons he enjoys working in development and design and showcasing his skills, especially at collaborative events like hackfests.
“I really like being able to think of new ideas and kind of throw stuff together to be able to create something that people can appreciate in such a small amount of time,” he says. “And, I also enjoy learning new technologies along the way.”
Free trial on Treehouse: Do you want to learn the design and development skills that employers want? Click here to try a free 14-day trial on Treehouse.
Hackfests have become popular in recent years as the development and design community pits teams against one another to craft new and often unconventional technology.
The-Hackfest.com, based in the United Kingdom, organizes and lists national and international projects bringing attention to the diversity of events happening around the world.
According to the site’s manifesto:
Hackfests used to be the domain of coding geeks getting together to show off their talents. Whilst that remains the essential heart of a hackathon businesses are increasingly realizing their worth too — and grasping the opportunity with both hands.
Apple, Facebook and Google are just a few of the companies that have opened up their ecosystems and essentially outsourced innovation to the masses and have hundreds of thousands of developers and others building products for them on spec. These massive developer communities are helping them truly innovate.
From hours-long to days-long events, designers and business owners also turn to hackfests because they often showcase programmers’ talents or can be the impetus for bringing a new product to market.
Mandle regularly participates in hackfests hosted by Boulder’s Quick Left, a firm that specializes in custom app development and consulting. The quarterly events have featured projects like a beerfest hackfest, a Bike-Month hackfest and a lock-picking hackfest.
Mandle and his teammate, Brian Shaffer, have won several of the events and usually are at the core of the team but have worked with other developers depending on the challenge, he says.
For the team’s winning design in the Rube Goldberg Machine hackfest, they leveraged the GNIP Twitter Firehose API to watch for any Tweets that contained #RubeGoldbergStyle. Then, using the Twillio API, a phone call was placed and when answered, read aloud the seventh #RubeGoldbergStyle tweet. That then triggered another call to a phone hooked up to a Pebble watch, which vibrated down a ramp, fell into a container, hitting the enter button on the keyboard. That then stopped the timer and played the Looney Tunes’ “That’s All Folks” ending.
Events like hackfests provide opportunities for developers and designers to mingle with employers. (Photo courtesy of 23rdstudios|Paul Talbot)
Another win for Mandle and his team included creating an app during Quick Left’s Bikes and Bytes hackfest that allowed cyclists to post what kind of ride they were taking on any day, whether road or mountain biking, to seek people with similar skills and plans.
“The cool thing about these is that they are borderline product ideas,” Mandle says. “We certainly could have turned to companies with the bike app and offered that as a product.”
Mandle participated in the Internet of Things Hackathon Finals in Las Vegas. With his team, Mandle showcased their creation, Spotiparty. It is a social and collaborative jukebox that allows guests within a preset radius of the hub — an all-in-one PC — to join the party, add songs, up-vote and down-vote songs and rock out.
See a presentation by Team Spotiparty:
Quick Left began its hackfests when the company started in 2011, says Rachel Scott, director of marketing.
Scott says the events started as a means for Quick Left to host get-togethers, pulling in designers and developers seeking another creative outlet.
“Primarily this started as a community-centric event,” she says. “One part of becoming a developer in open-source communities is it’s amazing the information that is available to learn. The community is amazing in that it collaborates. Another reason we do the hackfests is that a lot of coders are not necessarily coding on something they want to [in their non-hackfest lives]. Whether it’s a financial application for a client or something like that. [Hackfests are] an avenue for them to have a creative outlet.”
Quick Left’s hackfests have grown over the years, usually drawing 100 to 200 developers, Scott says. Scheduling the events around promotions like Boulder Startup Week also brings attention from people not necessarily involved in design or development. During the May 12 Battle of the Games hackfest, Quick Left also will host a retro-gaming competition, in which participants can enjoy playing original NES, Super NES, Gameboy and more.
In addition to highlighting creative design and development or introducing people to the industry, firms also have used hackfests to identify new talent and creative prospective employees.
“Quick Left has hired at least five developers from the hackfests,” Scott says. “This is a vastly different industry in terms of recruitment and hiring. Hackfests are great from that perspective. They are great for new and seasoned developers and businesses.”
For designers and developers, it is problem-solving with a clever or technical approach that can crack everyday or off-the-wall scenarios.
Also known as a hackathon, hack day or codefest, these are events in which designers and developers collaborate on technical projects, often shedding their everyday personas to enjoy beer, pizza and energy drinks in a creative setting. The events usually start with one or more presentations about the project. Participants then suggest ideas and often form teams based on interest and skills. The main work of the hackfest then begins, lasting for several hours or days.
At conclusion of the hackfest, participants offer demonstrations and present results. The events often are judged by organizers or sponsors. Some firms host hackfests as recruitment events, seeking new designers and developers.
Need an excuse to get creative in Colorado? Check out the next hackfest hosted by Quick Left from 6 p.m. to 9:30 p.m. on May 12. The event is a continuation of Quick Left’s popular quarterly hackfests that have seen designers and developers work a beerfest hackfest, a Bike-Month hackfest and a lock-picking hackfest.
On May 12, participants will be tasked with busting out their best hacked-together code with maze-solving, token-gathering and weapon-making skills as part of the Battle of the Games hackfest. Designers and developers can make their own adventure text games, tabletop games, MMOG or MUD games … all in three hours or less.
For more information or to register, visit http://quickleft.com/blog/battle-of-the-games-there-will-be-hackfest
To learn more about hackfests in your area, search engines offer dates and details. Globally, The-Hackfest.com organizes and lists national and international projects bringing attention to the diversity of events happening around the world. Register at www.the-hackfest.com.
The post Hackfests Are at the Heart of Creativity and Collaboration — and Beer Apps appeared first on Treehouse Blog.
]]>
 |
You probably know by now that you should speak with customers and test your idea before building a product. What you probably don’t know is that you might be making some of the most common mistakes when running your experiments.
Mistakes include testing the wrong aspect of your business, asking the wrong questions and neglecting to define a criterion for success. This article is your guide to designing quick, effective, low-cost experiments.
Four years ago, I had a great idea. What if there was a more visual way to learn about our world? Instead of typing search queries into a text field, what if we could share visual queries with our social network and get information about what we’re looking at? It could change the way people search! I went out, found my technical cofounder, and we started building a photo Q&A app. Being a designer, I naturally thought that the branding and user experience would make the product successful.
Six months later, after rigorous usability testing and refinement of the experience, we launched. Everyone flocked to the app and it blew up overnight. Just kidding. No one cared. It was that devastating moment after a great unveiling when all you hear are crickets chirping.
Confused and frustrated, I went back to the drawing board to determine why this was. My cofounder and I parted ways, and, left without technical expertise, I decided to step out and do some research by interviewing potential users of the app. After a few interviews, the root cause of the failed launched finally dawned on me. My beautifully designed solution did not solve a real human need. It took five days of interviews before I finally accepted this truth and slowly let go.
The good news for you is that you don’t need to go through the same pain and waste of time. I recently started working on another startup idea. This time, I followed a structured process to identify key risks and integrate customer feedback early on.
I work with many entrepreneurs to help them build their companies, and they always ask me for feedback on the user experience of their Web and mobile apps. They express frustration with finding UX talent and want some quick advice on their products in the meantime. This happens so frequently that I decided to learn more about their difficulties and see what might solve their problems.
I specified what I was trying to learn by forming a hypothesis:
“Bootstrapped startup founders have trouble getting UX feedback because they have no reliable sources to turn to.”
To test this, I set a minimum criterion for what I would accept as validation to further explore this opportunity. I had enough confidence that this was a big problem to set a criterion as high as 6 out of 10. This means that 6 out of the 10 people I interviewed needed to indicate that this was a big enough problem in order for me to proceed.
By stating my beliefs up front, I held myself accountable to the results and reduced the influence of any retroactive biases. I knew that if these entrepreneurs already had reliable sources to turn to for UX feedback and that they were happy with them, then generating demand for an alternative solution would be much harder.
Design of my first experiment on the Experiment Board. (Large preview)
In three hours of interviews, I was able to validate the pain point and the need for a better alternative. (You can watch a video walkthrough of my findings.) My next step was to test the riskiest assumption related to the solution that would solve this problem. Would they pay for an online service to get feedback from UX designers?
Instead of building a functioning marketplace with designer portfolios and payment functionality, or even wireframing anything, I simply set up a landing page with a price tag in the call to action to test whether visitors were willing to pay. This is called a pitch experiment. You can use QuickMVP to set up this kind of test.
Test if customers will pay for the service. (Large preview)
Behind the landing page, I attached a form to gather information on what they needed help with. Within a few hours, 10 people had paid for the service, asking for UX feedback on their websites. Having validated the demand, I needed to fulfill my promise by delivering the service to the people who had paid.
Did not build any functionality; just a form to collect information. (Large preview)
Because this market is two-sided — with entrepreneurs and designers — I tested the demand side first to see whether the solution provided enough value to elicit payment. Then, I tested the supply side to learn what kind of work designers were looking for and whether they were willing to consult virtually.
Test the second side of the market: the supply side. (Large preview)
To my surprise, the UX designers I spoke with had established clientele and were very picky about new clients, let alone wanting to consult with random startups online. But they all mentioned that they had been eager to take on any work when they were first starting out and looking for clients. So, I switched my focus to UX designers who are not yet established and are open to honing their skills by giving feedback online.
Armed with these insights, I iterated on my landing page to accommodate both sides of the market and proceeded to fulfill the demands of the customers I had accumulated. No wireframes. No code. Just a landing page and two forms!
A landing page that tests both sides of the market, simultaneously. (Large preview)
Interest in this service can also be measured by their willingness to fill out the form. (Large preview)
To simulate the back-end functionality, I emailed the requests to the UX designers, who would then respond with their feedback, which I would email back to the startup founders. Each transaction would take five minutes, and I did this over and over again with each customer until I could no longer handle the demand.
Do things that don’t scale in order to acquire your earliest customers and to identify business risks that you might overlook when implementing the technical aspects. This is called a concierge experiment. Once the manual labor has scaled to its limit, then write the code to open the bottleneck. Through this process, I was able to collect feedback on use cases, user expectations and ideas for improvements. This focused approach allowed for more informed iterations in a shorter span of time, without getting lost in wireframing much of the application up front.
Today, BetterUX.it is a service through which startup founders connect with UX designers for feedback on their websites and apps, and designers get paid for their expertise and feedback.
What did I do differently? The structured process of testing my assumptions saved me time and confirmed that each part of my work was actually creating value for end users. Below is a breakdown of the steps I took, so that you can do the same.
My first mistake with my first startup was assuming that others had the same problem that I experienced. This is a common assumption that many gloss over. Build products that scratch your own itch, right? But many entrepreneurs realize too late that the problems they’re trying to solve are not painful enough to sustain a business.
As product people, we often have many ideas bubbling in our heads. Before getting too excited, test them and decide which one is the most viable to pursue.
To get started, break down your idea into testable elements. An effective experiment must clearly define these four elements:
At Lean Startup Machine, we’ve created a tool called an Experiment Board, which enables us to easily turn crazy ideas into effective experiments in a few minutes. As you go along, use the board as a framework to design your experiment and track progress. Refer to the templates provided on the board to quickly formulate your hypothesis, riskiest assumption, method and success criterion. You can also watch my video tutorial for more information on designing effective experiments.
Every experiment starts with a hypothesis. Start by forming a customer-problem hypothesis. Once it is validated, you can go on to form a problem-solution hypothesis.
Now that you have formed a customer-problem hypothesis, poke some holes and extract the riskiest assumption to be tested. Start by brainstorming on a few core assumptions. These are the assumptions that are central to the viability of your hypothesis or business. Think of an assumption as the behavior, mentality or action that needs to be true in order to validate the hypothesis.
Ask your team members, boss or friends to suggest any assumptions that you may have overlooked. After listing a few, identify the riskiest one. This is the core assumption that you are most uncertain about and have the least amount of data on. Testing the riskiest assumption first will speed up the experiment cycle. If the riskiest assumption is invalidated, then the hypothesis will be invalid, and you will have saved your company from going down the wrong path.
After identifying the most critical aspect of your idea to test, determine how to test it. You could conduct three kinds of experiments before getting into wireframes. It’s best to start by gathering information firsthand through exploration. But you could choose a different method depending on your level of certainty and the data.
Before running the experiment, decide up front what result will constitute success and what result will constitute failure. The minimum criterion for success is the weakest outcome you will accept to continue allocating resources and pursuing the solution. Factors like budget, opportunity cost, size of market, level of demand and business metrics all play into it.
The criterion is usually expressed as a fraction:
“I expect x number of people out of the y number of people in the experiment to exhibit behavior z.”
I like to set the criterion according to how big I think the problem is for that customer segment, and then determine how much revenue it would have to generate in order for me to keep working on it. At this point, statistical significance is not important; if your target customer segment is very specific, then testing with 10 of them is enough to start seeing a pattern.
Once you have validated the hypothesis with a small sample of the customer segment, then you can scale up the experiments to test with larger sample sizes or with other segments.
Once you have defined these elements, you are ready to run the experiment! Have team members look at your Experiment Board and confirm whether they agree with what you’re testing. This will hold you and the team accountable to the results, so that there are no subjective arguments afterwards.
After gathering data from your target customers, document the results and your learning on the Experiment Board. Did the results meet your criterion for success? If so, then your hypothesis was valid, and you can move forward to test the next risk with the product. If not, then you need to form a new hypothesis based on your learning to get closer to something that holds true. Track your progress over time on the Experiment Board to get a holistic picture of your validated learning and to continually make informed decisions.
Test and repeat. You’re on your way to creating a great product that people want!
(al, il)
© Grace Ng for Smashing Magazine, 2014.
]]>I've had the pleasure of being on a couple of podcasts recently other than ShopTalk (where we most recently interviewed Julie Ann Horvath about, among other things, her GitHub exit).
I was on How to Hold a Pencil where Reuben Ingber and I chat about what it's like to be a beginner and where to go next.
I was on Pencil vs Pixel where Cesar Contreras and I talked about capturing ideas, motivation, and the future.
I was on the CDNify podcast as well.
Spring is breaking finally here in Wisconsin so it feels good to be back biking around town. I've been doing a good job at going to the gym and sticking with my training. We even trained outside today for the first time this year.
I'm just about to take off for a few weeks though. I'm headed down to Tampa, Florida to see some friends (I used to live there, back in the Wufoo days) and we're also getting together there as Team CodePen for an in-person sprint.
I leave from Florida and head up to North Carolina where I'm picking up a new camper trailer, the SylvanSport Go, which I'm pretty stoked about. It just so happens that MerleFest is going on at the same time so I'm going to meet some of my bluegrass buddies there for the weekend.
Then I need to high tail it back to Wisconsin because I have a flight down to Champaign, Illinois for the University of Illinois Web Conference where I get to keynote one of the days.
From there I fly to Columbia, South Carolina for ConvergeSE.
Then finally back home, where I only have a week before another big adventure. I'll save that for next time.
We've been hard at work at at CodePen. The new feature releases were a little slow for a while because we were buried in a huge one: Teams. It might seem like a simple thing, but it was anything but. We even talked about it a bit on the podcast.
Perhaps I haven't mentioned here? We're doing a new podcast over at CodePen, a kind of self-documentary of what it's like running a web software business. We call it CodePen Radio.
Taxes are another thing on my mind. They are due the 15th here in the US, and despite starting on them as early as I could, I'm cutting it down to the wire. It's crazy how late you can get needed documents to do it all properly. I think I'm just about done and it's a very painful year (mostly due to my own lack of planning in paying quarterlies). Gonna have to tighten the belt for a few months.
CSS-Tricks Chronicle XVII is a post from CSS-Tricks
]]>