We built a remote communication tool for our friends at Zapier.

Zappy allows you to quickly share annotated screenshots, screencasts and GIFs.
It does what dozens of other tools do in bits — but we wanted to build an all-in-one native Mac app with relentless focus on speedy UX.
Zappy has been heavily used by Zapier’s internal team for more than a year — and we have been told they love it!

A large part of the world has to suddenly work from home — so Zapier decided to make Zappy available for free to the public.
After all, their impressive internal engagement and retention metrics were the key driver behind this.

Less misunderstandings with screenshots and colored arrows

It’s so much easier to get context across if you can add little images with arrows and rectangles to your messages. This is true for internal team chat, email or communicating to customers via helpdesk software or community forums.

Zapier even uses Zappy for all the annotated screenshots in their blog posts and helpdesk articles.

Zappy is all about speed — auto-uploading, keyboard shortcuts, minimal steps

Using visuals in chat communication is optional — speed really matters for adoption. Every extra step, every bit of latency affects usage.
Your brain decides in miliseconds if its worth going through the effort of taking a screenshot and putting arrows on it or rather to type out an extra couple sentences to get your point across.

Level-up from screenshots to screencasts — with a single shortcut

Zappy let’s you select the screen area you want to share with a single shortcut.
If a static screenshot is enough you can share a link to it right away.
Feel like going the extra-mile — turn on the webcam, use your mouse to point to things and add your voice to it.
We try to make the transition from static screenshots to rich screencasts as low-friction as possible.

Zappy let’s Zapier keep company-wide screenshots and screencasts in a central place, enabling re-use and moderation of sensitive content

Central storage on a company-controlled AWS S3 bucket was a key requirement for building Zappy. Support teams take screenshots all the time in their customer communication — if sensitive data was captured it can easily be removed even after the link was shared.
For helpdesk content, Zappy becomes a low-friction and reliable place to host any assets.

Zappy makes images in Markdown less painful

Zappy auto-uploads screenshots and give you a link to the raw image. To the raw image — not some magical resource that wraps a bunch of html and js around it.
This means you can directly embed it into markdown.

Need to put a series of images into your document? Zappy gives you the link instantly, even if upload is still in progress or you are offline.
If you have tried to put lots of images into a markdown document, you may appreciate this little feature.

Give Zappy a spin and let us know! We’ve got a few more things in store.

• Get Zappy
• Zappy on ProductHunt

Launching Zappy for remote teams — Zapier’s fast, free screen capture tool was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Are you using Slack to get approval from your team before scheduling your company’s content?

If you’re having these conversations on Slack:

• Discussion about content ideas
• Best time to post
• Hashtags to use
• The final approval of copy and assets

Then shouldn’t you be able to schedule in Slack too?

We think so. That’s why we built a bot that allows you to draft, discuss and schedule all your social media posts directly from Slack!

With this app, the conversation history and actions taken for each social media post is neatly organized under one thread. So that your content ideas become scheduled posts as smoothly as conversations flow.

Let’s see how it works:

It’s the last day of work at your sweater factory before Christmas holiday. The content schedule needs to be finished before you’re off to sip eggnog with your loved ones. Hera, your content editor sends your Christmas post to the #content-approval channel in Slack.

Your team weighs in and you agree. Since no one else has any input, you decide to schedule it for December 25th at 11 AM.

Hover over the message that contains your post. Click on the three dots. Choose Schedule Post on Hootsuite.

Next, a pop up modal will appear.

Choose your platforms. We are posting on Instagram.

Choose the date and time agreed, while the copy is automatically taken from your Slack message.

When your post has been scheduled you will receive this message with a link to the Hootsuite post and a thumbnail of the image you uploaded.

Now you’re done —

But, wait…

Sara from sales just added a comment on Slack!

You should definitely add that!

Go back to the Slack App thread showing your scheduled Hootsuite post. This time choose Edit Post on Hootsuite.

A modal pops up so you can directly edit the caption, and other fields if necessary.

When you are finished, click Submit Changes and you will receive a message of confirmation.

And there’s more.

If you or someone on your team is unsure whether or not you have something scheduled for a specific date, you or them can use Slash commands to see what has been scheduled.

In Slack simply type

/scheduled date

Your Slack app will return the posts scheduled for that day with image and caption.

Finally, on the date that your content is posted, you will receive a message on Slack with links to all the platforms where it was posted so you can check their performance later.

What do you think? Do you have a similar workflow but with different apps? Let us know!

We are beta testing our bot with some marketing agencies at the moment but would love to get it in the hands of more folks.

Sign up for beta access → https://forms.gle/2nQ21GAATTJ6oZBJ9

Until the next bot!

Content Approval Slack app with Hootsuite was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Facebook Group Newsletter

We run a facebook group where members share tips and ideas about Zapier, the app connector and workflow automator. Check out our Zapier Automation Experts group here.

We wanted to start a newsletter for our members, but realized that getting emails from our members was a painful manual process. Since our core operations are apps, automations and app integrations, we had to build a bot. The workflow comprises the Facebook group, Telegram and Airtable. Here’s the story:

Collecting emails from group request forms

Facebook doesn’t provide the email address of group members so we asked new members for them the only way we could: with the Facebook group request forms.

People began giving us their email addresses for our newsletter, but we couldn’t save them! We accepted the first dozen people before realizing that after we hit ‘Accept’, the questionnaires disappeared forever effectively losing those email addresses. (If you believe we lost your email address because you’ve never received a newsletter and would like one, sign up us.) We needed another way to store these email address.

We began taking screenshots from our phones of the requests before accepting them. We kept these in a shared folder while we figured out when and how to extract them.

Keeping Facebook member approval screenshots for lack of an export

We finally had many email addresses and time to devote to the newsletter, but no one in the team was up for the task: reading JPEGs and doing data entry. Besides, the opportunity cost of having their talent and efforts spent on this task was too high. We knew we needed non human help.

Using a Telegram OCR bot to automatically extract emails from screenshots

First, we decided where we wanted to keep these emails. We chose Airtable: a database meets spreadsheet with tons of functionality and integrations that we would need in the future when we launched our newsletter.

Then, we decided in what app we would build the bot. We chose our most used messaging app, Telegram, because we spent a lot of time there and it has a really easy file sharing UX for mobile devices. (We’ve since developed a Zapier app that does this too with Slack. Sign up below to become a beta tester.)

The workflow would be this:

1. Review Group requests.
2. Take a screenshot of the request from our phones before hitting accept.
3. Open Telegram. Select the thread with the bot and dump the screenshots there.
4. The bot reads the image and extracts the email addresses and other details.
5. The bot sends the data to our newsletter base in Airtable.

The resulting bot was a practical and slightly rude helper. Rude because we programmed it to tell us a mean joke every time a screenshot was uploaded to the chat.

“If you’re going to be two-faced, at least make one of them pretty.”

That, of course, was unnecessary, but it makes us laugh every day.

If you want to try out our Zapier OCR app that also reads email addresses from Facebook group membership requests (but DOESN’T insult you), let us know your usecase here→ https://forms.gle/7xxefxwSa7jPh3JJ7 to get signed up to be a beta tester.

Until the next bot.

We Built A Telegram OCR Bot That Reads Email Addresses from Facebook Group Requests was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was lucky to start my work at Blackbelt Labs, on day one of the design phase — the first stage of actual hands-on app development. I say actual app development because everything preceding it involves many, many conversations to help the client discover what they need. We call these road mapping workshops. Once business objectives are understood and stakeholder needs are identified, it was time to understand the users.

Mapping Their Journey
For this project, we partnered with a prefabricated home company.
They wanted an app that aids mostly first-time homeowners through the house building process. This was a challenging — but exciting — project for our team. Building a home can be a daunting experience just by the sheer size and complexity of the undertaking. However, the palpability of an actual home was irresistible to us since we are used to working with virtual elements in small screens. This was our chance to work with both the tangible and virtual.

But first, how do you build a prefabricated house?

To find out we had to speak to our client’s former clients. We arranged interviews with dozens of homeowners who had gone through this long process and they helped us map it out. From the signing of the contract to the financing to the floor tile and appliance sampling, all the way to the home unveiling. These were some of the steps. But we were also interested in how the future homeowners were feeling throughout the process.

Users Are Emotional
At the interviews we spoke not only about the process but what it felt like to go through it. Our goal was to identify the problems that caused the negative feelings and to come up with features to alleviate them.

We were also interested in the positive feelings to somehow highlight them in the app. For example, a splash screen with words of encouragement or congratulations after completing a particularly difficult stage. Post interviews, we went back to create a customer story that mapped important events and tasks plus feelings and concerns.

Keep It Simple — MVP

From the first round of user feedback, we came up with many features and functions, however, when creating the first iteration on an app all we needed was an MVP — minimal viable product. But why just minimal? Because our list of seemingly useful features were just assumptions based on user’s feelings, concerns and suggestions. The only way to validate those is to actually test them with real users later on in the process.

Content First Design, or Lack Thereof
We engaged an experienced designer and provided him with our User Journey Map annotated with emotions through the use of Emojis.
The map also included the features and desired functions of our MVP. However, the designer, like us, needed more.

The concepts were strong but the content was missing on the client’s side.
We didn’t have enough details about what exactly would go in the app.
For example, one feature was checklists.

The year-long process was divided into stages and within each stage, there were certain tasks that had to be completed. The homebuyers said a checklist for the task would have helped them execute especially when it came to the tasks that required that some documents were printed and signed. Even though we knew the stages, we didn’t know the tasks nor the documents necessary.

During this stage, I realized the importance of Content First Design — or the idea that in order to design effectively the designer must know the context and content well. Without it, the design process took much longer and required more revisions as content details came in and we had to solve again for sizing, colors, margins, layouts, etc.

Click Dummy
Time constraint forced us to work without content to start, but we eventually received full content details and were ready to demo our click dummy to users. We got a great response, and from the feedback, we made some adjustments to the UX and validated them with users again.

Next phase of production will be the coding, but the user validation does not end there. The next set of features would go through the same process: research, assumptions, design based on content, and user validation.

The importance of iterating on a controlled set of features to start (MVP) through user feedback was, for me, the biggest takeaway.

When you begin to design your product remember to keep the first iteration simple, to design around content and to validate all your feature and design assumptions with the homeowners.

Developing An App For Prefab Homes Buyers — The Design Phase was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Blackbelt Labs we recently had a client come to us with an app that needed to be revived. The backend had been built using Parse provided by Facebook. Meanwhile Parse has gone open source and the Facebook hosting option is not available anymore. Because of this the app stopped working. In order to get it to run again we had to do at least two things.

• Find a new hosting solution for the Parse backend
• Make the app work with the new backend

Finding a Parse alternative

So what we had to find was either an option to get Parse to work again or hook the app up to a new backend solution — Firebase came to mind.

After some research it turned out there were roughly two options if we kept Parse. Either we host our own Parse server on something like Heroku, Digital Ocean, our basement or we choose a managed version from companies like Sashido.io, Back4App and so on. Since the target of this project was just to revive the app as soon as possible we decided to use Sashido.io. We liked that they were operating in the same timezones as us and also they seemed like a quite early stage startup which we hoped would mean fast support. Since we had found a promising solution that allowed us to keep using Parse we headed on to the app itself.

Migrating from Swift 1 to Swift 3

The app had been built in Swift 1. We are now at Swift 3 with Swift 4 on the way. Some people might remember how naughty working in Swift 1 could be back in the day so I was prepared for battle when I opened the project in my current version of XCode. Of course I was greeted with a lot of errors and warnings. This was also my first time working with this app as I had not been part of the team that built it. I decided to just get it to build first. This meant getting rid of all the errors. There is an automatic migration that XCode does for you which was helpful but didn’t solve all the errors and warnings. I then started wielding through the error jungle line by line looking up API changes when needed. Sometimes this was easy and sometimes this was more tricky. The trickier parts were when I had to update core graphics components on which our app heavily relies.

For example, this….

let subPath = CGPathCreateMutable()

CGPathMoveToPoint(subPath, nil, x, y)

CGPathAddQuadCurveToPoint(subPath, nil, x, y, x, y)

turned into this:

let path = CGMutablePath()

path.move(to: CGPoint(x: x, y: y))

path.addQuadCurve(to: CGPoint(x: x, y: y), control: CGPoint(x: x, y: y))

At some point I got the app to build. Before it was time to hook it up I had to update our version of Parse to the most recent one. After trying to manually move the framework I decided to try the quick route and used cocoa pods. This worked instantly. The app was now without errors and ready to be hooked up to our backend!

Parse hosting with Sashido

The first thing I had to do was get an account with Sashido.io. They give everyone a 14 days trial with full features. It went smooth and fast, you don’t even have to give them your paypal or credit card credentials upfront. In their dashboard you get a little tutorial with a code snippet to hook up your app. I fiddled the snippet into our existing code and it worked right away.

Deploying cloud code

Our app also used some cloud code to work with Twilio. Sashido provides you with a private Github repo to upload your cloud code. You just clone the repo, put your code in and push it. It is automatically built and deployed. After this our app was ready for a first test run — what can I say, it worked pretty much right away!

Setting up push notifications on Sashido

The only thing that was missing now was push notifications. All you need to do for this to work is set them up and upload your P12 file to Sashido. This is done with a simple drag&drop. In the beginning I had some problems here because my setup was not correct, unfortunately in this case Sashido only tells you when push notifications have failed but there are no logs. I had to send my first support request. It took maybe 2-3 hours to get a reply where they gave me the log for my failed push notifications. While the support was swift it would have been nicer to just have the logs instead.

Parse debugging issues

After we got push notifications to work we sent the app for our first feedback round back to the customer. They came back to us with some minor bugs and two new feature requests. To make these features work we had to write some cloud code. This is when our decision to go with a managed solution came back to haunt us. Since we didn’t have a local server to test our cloud code I had to always push to the server to test my changes. I wrote a quick git alias for this to speed up the feedback loop.

alias splurge="git add . && git commit -m 'another attempt at debugging' && git push origin master"

My only way to trouble shoot the code was either to use good old console.log with my code that sat on the server or come up with some interface in the cloud code to expose data back to me. After spending what felt like way too long on getting some basic functionalities set up I sent another support request about how to debug the cloud code. A big problem was that it turns out Parse server has a problem with console.log — as in, it just does not work. Unfortuntely I did not know this. I will write this fat so no one ever has to suffer the way I did again. Use console.info or console.warn if you need to log something on the Parse server. When I found out that this actually worked I was done very quickly.

Conclusion

Anyways — at this point we had revived the app completely and even added two features. It went smoother and faster than expected. The decision on whether you want to use a managed hosting solution, a self hosted solution or a new framework comes down entirely to your expertise with Parse and Node or something like Firebase. For me I didn’t have much or any experience in any of those so I stayed as close to what we already had as possible. At some points it would have been nice to have a local server to trouble shoot but in the end the only blocker was that I could not use console.log. Other then that a really smooth experience considering I had never worked with Parse and I had not written the app that needed to be revived. Would I use Parse if I had to build an app like this today? I’m not so sure. Googling for errors or potential solutions did not always leak up to date results or any results for that matter. For this project I think we did the right thing, kept it very lean, made our customer happy quickly and provided them with a user friendly no strings attached backend solution.

Reach out to us at Blackbelt Labs if you need help with reviving your Parse based app.

Migrating a Parse backend was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Realising the first version or an date of your app always requires testing it beforehand. The first user impression matters. If something didn’t work out as expected the user might be gone forever. Testing is a core concept that helps building trusted relationships with your users.

I believe that the adoption of a tool is a good indicator of how reliable it is. You do not want to end up spending time implementing a tool that barely has users, is likely to be buggy, and possibly disappears soon.
In terms of adoption, there are three outstanding solutions for bug, crash reporting and beta distribution needs: TestFlight, Fabric (Crashlytics) and Hockey App.

I have defined ten criteria besides adoption that can help you choose the right tool. A more detailed explanation of each of the criteria is below.

Platform Support

The number one reason to favour one of these tools over another is the platform or platforms your app is built for. If your app does not run on iPhones or iPads, you can ignore TestFlight. If your app has both iOS and Android versions it makes sense to combine TestFlight with Fabric or Hockey App. The last two are a necessity for Android and are complementary to TestFlight’s features. However, it is a common good practice to have “one source of truth” for different platforms. Either Fabric or Hockey App can perfectly fit the role of this “source”.

Ease of Setup

The next important criteria is the time your team needs to spend implementing a certain tool. In this regard Hockey App is the most time consuming. If gathering feedback and managing lists of testers is not a necessity I would rather go with Fabric or TestFlight.

Review Time

For Android there is no review required — your app can be instantly tested. Even for deploying in the Google Marketplace there is no review procedure.

For Windows Phone the reviews takes up to 5 working days. There are certain types of betas that can be available faster but in this case your beta and your app are different things and you would have to manually transfer data from one to another for an official release.

For iOS the review time differs between the type of testing you want to organise. If it is an internal test among your colleagues or family members you can add up to 100 testers through you Apple Developer account and your builds will be instantly available to these people.
For external testing the TestFlight review time for a new app and each release is about 24 hours. However there is a trick how you can save your app from 24 hour breaks. The next time you submit changes to the same version of the app, do it without launching a new one.

Maximum Number of Testers

For Android and Windows Phone — you can invite an unlimited number of testers using either Fabric or Hockey App.
For iOS the maximum number of testers is restricted by Apple and applies to all tools including TestFlight.

Ease of Inviting Testers

Bulk inviting testers to your app can be a minor feature if your team is small (let’s say up to 20 people) and you don’t have external testers. In this case Fabric can serve you well as this tool allows inviting one tester at a time by manually adding his email address. With TestFlight and HockeyApp you can invite a list of testers by uploading a CSV file.

Segmenting Testers

Segmenting testers is a feature that is available in each tool. The only difference is user friendliness of its implementation. It was hard to find tester grouping functionality in Fabric, for a long time I thought they just don’t have it.

Multi Version Testing

Multi version testing can significantly speed up the process of building and launching an app. It is a vital feature for apps in highly competitive markets. Both Fabric and HockeyApp provide multi version testing. A few months ago, TestFlight also added this functionality in beta mode.

Tester Onboarding

TestFlight tester onboarding is harsh. You send an invite, the user follows the link from the email and gets referred to the AppStore to download TestFlight. The user flow is very confusing. From experience, only around 5 to 20 percent of invited testers complete the process.
Fabric and HockeyApp provide a way better tester onboarding experience. Testers get an invitation via email, follow the link and press a download button after entering their name. The beta app is now on their device.

Gathering Feedback

The way feedback functionality works on TestFlight:

Yeah, that is it. Testers can send an email! Not very advanced feedback tooling. But Fabric doesn’t have any at all. From this perspective HockeyApp is the only proper way to go. Testers can even create video records of things that are confusing or work wrong to them. For big organisations where different departments or stakeholders are involved into the app testing process HockeyApp is the only viable solution on the market.

Performance Reports

TestFlight has very basic crash reporting — it simply shows the number of crashes per user. The absence of detailed crash reporting is one of the main reasons why TestFlight is commonly used in tandem with some other tool. Both Fabric and HockeyApp provide a broad range of bug, crash, engagement and event reports. Fabric recently even added a separate revenue report.

Unique Features

I believe Fabric’s popularity is driven by the broad range of third-party integrations. It is way easier to get data out of this tool. Being able to easily share results via GitHub, Slack, Jira makes performance visible and accessible to everyone in the team or even within the organisation.
Unique to HockeyApp is to me its active support community via Slack or email. When you need real people to help, you can get it fast with this tool.

After giving a talk on this topic I was asked about my favourite mobile analytics stack.
I can’t name a one size fits all solution. For example I definitely prefer Fabric’s user experience over HockeyApp. But the former does not allow you to invite hundreds or thousands of testers at a time or group them easily by certain criteria.
You need to identify your problems and define your goals to choose a stack that fits your product. Be careful choosing, ho-ho-ho… as migrating to another tool is honestly a pain and a big waste of time for your team.

Reach out to us at Blackbelt Labs if you need help organising mobile user testing and setting up an analytics pipeline.

A Guide to Mobile Analytics 🔧 Part I: Beta Distribution, Bug and Crash Reporting was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

It was in March 2015 when my good friend Johannes and I decided to jointly launch a freelance business for app development.
We were both based in beautiful Heidelberg and had been hacking together on various apps, open source and compiler development for years.

As we did not want to build just another all-in-one tech agency we exclusively focused on app development for iOS, only later adding Android and web apps.
This proved to serve us very well — we quickly became known as the go-to app developers in the Rhein-Neckar region in Germany.
We further expanded our reach to the US with the help of our fantastic design partner Joey Primiani. Joey was recently listed in Forbes 30 under 30 and connected us to a number of exciting startups in California.

We were lucky to get a great office in the Dezernat16 startup center in Heidelberg. We did not manage to get the garage but our space still looks very much like you expect it from a bootstrapped business.

While I have been traveling around the world most of the time, it is still great to have a common base to meet.

Besides bringing us a number of local startup clients our office is a popular space for tech folks to just hang out and hack on stuff.
This way we very organically had three more team members join without us actively looking to grow. Konrad, Sebastian and Christian help us deliver on the ever growing demand for mobile solutions.
We further continued to grow our network of freelance partners which allowed us to take on larger projects.

Its been two years now and we are truly proud of what we were able to deliver in that time.

We built IoT solutions for robotic systems in manufacturing, worked on wearable fashion products presented at the New York Fashion Week, built a car-sharing platform, helped transform a large cruise line and much more.

We are especially happy about being able to work with startups, major enterprises and German “Mittelstand” companies at the same time. Each client has its unique challenges but there are many learnings that can be transferred between engagements.

In the next weeks we will work on showcasing some of the products we helped build and highlight key insights. So keep watching our blog.

Until now our growth has been purely based on word of mouth — we did not have any kind of active branding nor a real website. Client engagements mostly happened based on personal relationships of Johannes and me.

From this month on we are changing that. Joey Primiani, Nico Saueressig and Olga Kostova are joining our core team. Together we are launching Blackbelt Labs as a common brand identity and try to be more vocal about our work.

Joey brings in award-winning design skills and an excellent network in California and beyond. I will work closely with him to expand our US client base. At the same time his background will help our clients in Germany to iterate even faster from app prototypes to polished products.

Olga has years of experience in analytics and digital marketing, these skills are excellent complements to our app development offering. She has worked with a range of startups in 3d-printing and e-commerce as well as with enterprise clients in retail and travel. We are therefore proud to be able to offer professional help with KPI tracking and conversion optimization.

Nico joins us with a well-rounded background in mobile, backend development and DevOps and a good portion of entertainer skills. Nico and I are good friends since childhood. He previously worked at Shutl, a same-day delivery startup which was acquired by eBay. Being tired of enterprise employment we have long been in discussion to join forces.

At Blackbelt Labs we are shipping connected apps, backed by actionable analytics and lean infrastructure.

We will continue to strike a balance between startup and enterprise engagements. Our ideal client is open for remote collaboration combined with intense on-site periods. We are most effective when working on products as a full team, bringing together our design, analytics and engineering background.

Reach out to us at blackbeltlabs.com if you want us to help connect with your mobile audience in the best possible way.

Launching Blackbelt Labs was originally published in Blackbelt Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.