Coding Archives - LunarLincoln

Sep

Gif TV: A LunarLincoln Product

If you’ve ever perused our blog or Twitter you might have noticed that we like GIFs. We think they’re a great medium for injecting humor or emotion into what could otherwise be a dry industry-specific topic. If you’ve ever been in our company Slack or on a text thread – you’ll notice we sling just as many GIFs there too. We just can’t get enough of those little moving-nuggets of fun.

What feels like 1 million years ago but was actually 2014, I found an article on Lifehacker (remember Lifehacker?) about building a little screen that showed GIFs. I was fascinated, immediately ordered the parts and put one together (although not without copious cursing due to the inaccurate instructions). This lil’GIF machine resided on the wall in our office for a few years but was more frequently out of commission than active. It was the definition of a buggy hack.

I loved it. I loved the serendipity of a random GIF being served up as well as the mindless entertainment of seeing what comes next. If you’re a fan of the TikTok For You page, you know exactly what I mean.

So, when we first started clearing time in our schedule to work on passion-projects at LunarLincoln, we each made lists of potential ideas we’d like to work on. Wiley made a huge list of tools that could help him at work/life (to do apps, API validators, proximity photo services). Me? I made a huge list of fun, useless things (80s photo filters, mean mail and….the Gif TV).

I wanted to see our office Gif TV as a real product, for real (non-technical) people. It could show your favorite GIFs, GIFs from friends, GIFs for topics, reaction GIFs, etc. Whatever hit of 5 second dopamine-laced entertainment you needed.

Wiley begrudgingly agreed (since I promised to do most of the work). And so we dug into building Gif TV.

Below is a very quick summary of the journey but we’ll be breaking these into longer posts in the coming days. Keep checking back for more product and GIF content!

Initial Plans & the Reboot

Initially our plan was to package up the original raspberry pi/screen concept with a companion app to select and serve the GIFs since the initial version you had to upload GIF files by hand to a random database. But, as I started to source components, and look at 3-D printing cases, and see how long it took to assemble them by hand – it was seeming a more and more complicated (and not profitable) venture. Hardware is hard y’all.

But what if the app WAS the tv?

This would be a simple solution. We build apps. Why muddy it up with hardware?

BUT, I did still want some sort of physical component for two reasons.

People are so fickle about paying for apps – a physical product still holds more “value” for consumers. We could recoup costs better upfront than trying to build out all the infrastructure for some sort of subscription service.
I wanted a physical engagement with the gifs. We already have a million ways of digitally access gifs, but what about a “present” version. I pictured the app languishing with the 1200 other random things you downloaded into your phone. That physical stand will be sitting there, asking – don’t you want to stream some gifs today?

So the GIF TV was reborn – an App + a Stand.

Coming soon – Learn more about the app planning process and the stand production process.

Gif TV as a way to learn new tools/technologies

The Gif TV project wasn’t just a way to share our office Gif TV with friends though. We wanted some low-risk projects to test new tools on.

Personally, I wanted to take Figma for a test run without using a client as a guinea pig (and on something more complex than twiddling with the pre-built templates).

Wiley had wanted to check out Flutter. After years of nay-saying cross platform solutions, a few close friends had managed to convince him that Flutter was worth a gander. Cross-platform still is only best used for content-driven apps versus sensor driven apps and Gif TV fit this niche perfectly.

Gif TV seemed like the great solution for both goals. Fun product + acquiring new skills. Double win.

Coming soon – Learn more about why we’re fully on the Figma train now and about Flutter and when it’s best to use.

Gif TV as a foray into new activities (crowdfunding, marketing, startup sites)

We weren’t just learning new skills for our careers though, we did a little stretching into adjacent areas too.

I learned more than I ever wanted to know about laser cutting and CNC machines. I built stand prototypes with my Cricut, had early versions cut with Ponoko, and now I have a cardboard box with more random Gif TV stand pieces than you’d even need.

We tried out new kind of promotional websites – falling in love with Carrd for it’s simplicity and inexpensive entry point for landing pages and Big Cartel for our shop.

We stretched our marketing skills again for the first time since CaseCollage. We gained a newfound respect for how lucky we’d been with that first launch and just how many new things there were to learn in this go-round. Product Hunt, social campaigns, cold emails – they were all areas where we felt we were just dipping out toes and learning there was a lot more to learn.

Coming soon – Learn more about our experience with Product Marketing.

Gif TV as an enjoyable product for friends

At the end of the day, we haven’t seen as much traction as we’d hope for our little Gif TV. But that doesn’t mean it can’t still happen or that I’m not still enjoying my personal Gif TV streaming on my desk right now. We’ve learned a ton about Figma, Flutter, Kickstarter, Product Hunt, lasercutting, ecommerce and social media. I think we’re better positioned for future product launches and we have a great little product here as a case study.

We’ll likely push Gif TV some more during the holiday season and I’ll work on some alternative marketing for it in the meantime.

Want to check out Gif TV for yourself?

Visit the site where you can download the apps, purchase a stand, or learn more about all the ways you can enjoy your own Gif TV.

Nov

Onboarding other peoples code

Greenfield vs Brownfield

There’s nothing better than cracking open your laptop, selecting “New -> Project”, and starting to build an app. At this point your codebase is flawless, your app builds and runs in seconds, and there’s no tech debt. Every thing is in the right place, and you feel like you can conquer the world.

But there will come a time when you have to work with other people’s code. You inherit an existing codebase when starting a new job. Or you get a new client who has a working app that needs features added or production bugs squashed. Or you get the opportunity to rescue a project that’s over budget and timeline and needs to be shipped ASAP. Whatever the case might be, there’s an existing codebase that has perceived value and its up to you to add to it. So where do you even start?

Documentation

At LunarLincoln, we like to start by carving out some time to review the project. If there’s existing documentation, start there. Now that you’re working on the project, documentation is your responsibility. Make sure to update existing documentation if you find errors. If there’s no documentation, document things as you go. Then use the app like a real user would. Start making a list of questions as you go and work with stakeholders or previous developers to get answers to those questions. Having a good spec is the first step in contributing to an existing codebase.

Code Review + Red Flags

After you know what the app’s supposed to accomplish, dive into the code. Start by building the app from the latest commit that was deployed. Be on the lookout for red flags (and yes, document these as you go).

Red flags come in many forms, and you’ll get better at spotting them the longer you work with apps. Here are a few we typically look for when onboarding a codebase:

An egregious number of build warnings
A disorganized project structure
A few classes with a lot of code in them or a lot of classes with almost no code in them
Poor or inconsistent naming
Breaking the defined architecture of the app (i.e. if MVC seems to be the convention, having the view accessing the model layer directly)
Code that solves widely solved problems
Dependencies that have little to no community around them

Fix Something Small

From there, take a quick, deeper dive into the project to get a feel for working in it. A great place to start is trying to fix an existing bug. This’ll give you an idea of what working in the codebase is actually like. It’s impossible to fully understand a codebase that took months to build in a review lasting hours, but at least you’ll have an idea of how to set expectations moving forward.

Document + Present Your Findings

Once you’ve had a chance to review the project, make a list of things that need to happen to move the needle on the project (you were doing this as you went…right?). Then categorize that list by urgency. You’ll probably want to fix everything before getting started with new features or bug fixes, but some things will absolutely be more urgent that others. The important part is that you communicate what you find to your stakeholders, agree on a plan to fix things, and start producing value. For existing apps, try to remember that the app people are using in the wild was made from the code you already have.

Become the New Code Master

Switching developers on a project is an expensive undertaking. Save yourself a headache later by reviewing the documentation, app, and code up front. Then leverage the findings in your review to lay out expectations and a roadmap for continuing development on the app.

Jun

Don’t build it all. Picking a Platform.

Often a client’s first knee jerk reaction is to want to build their product on as many platforms as possible. “Our customers and our admins need to be able to access their account online and on a mobile app and maybe on a desktop program.”

And then when we suggest maybe only doing only one of those…they get…kinda hostile.

They think that we don’t believe in this big idea. Or we don’t want to help all their users. But, this isn’t it at all! By telling you no, what we really mean is that we want you to be successful! And successful when you’re a fledgling startup means starting small and focused.

We totally get it. You don’t want to miss out on an opportunity to connect with a potential user and their potential money just because they can’t access your product easily, but trying to build out multiple code bases without any initial customers or validation is a very. costly. mistake.

The first thing you should code up when starting a new product is an MVP…or a MINIMUM. viable product. Does building your first product for multiple users to access online, on phones, on tablets and on desktops sound very minimal? Nope.

So what should you do? Which should you pick? How do you even do that?

Don’t worry! We can take a quick look at a couple of different aspects to decide which platform is best to start with.

First let’s look at what kinds of tasks your product will contain.

Will your users need to type in a lot of text?
- This will mean your product needs to run on something that has a real keyboard. (Web or Computer Program)
Will your users need access to a camera or video? What kind of photos or video are your users needing?
- Is it candids like Snapchat (App)
- Or is it more meetings like Zoom (Web)
Do we need the user’s location? How accurate does this need to be?
- If we’re offering some sort of running, fitness, or habits product we’ll need an app that can offer that hyper detailed data.
- If we just need to know nearby items (think Yelp) then maybe typing in our zipcode on a website works.
Does this product need a really high level of visual polish or performance?
- Depending on its speed and visual needs, maybe don’t consider a hybrid app or web app for starting off.

Then look at where these kinds of tasks will be done.

Are they needing to do these tasks while out and about? (Phone or Tablet App)
How about offline/no service areas (Native Apps)
Is this daytime, office work? (Web Browser or Computer Program)
Is this an evening, couch activity? (Phone App / Responsive Web)

Who will be using this product?

Kids? – Most kids use inexpensive tablets
Office staff? Maybe custom software or web service or inexpensive android tablets
Gen Z? New Moms? Senior Men? – Each demographic migrates to a certain kind of device depending on finances, habits, and age.

Now of course, people have varying habits and not every single user you talk to will say that they want to access your product in the same place. (In fact most users will say that they want more choice – even if their actual habits show them using the same devices over and over.)

So what you’re doing with this exercise is deciding which platform has the most logical overlap for all of these questions/answers for your target user.

Sidenote: Pretty much ALL of our advice at LunarLincoln involves touching base with your users and their needs. Make sure you genuinely understand your “core” user and remain focused on them. If you’re not sure how to do that just yet, check out our article on “Knowing your Users”.

Okay. I know more about where my users are and what this product might need, now what?

Now, pick ONE PLATFORM for your MVP.

Only one? Really? But…but…I can’t! I need them all. This way I don’t miss out and ALL of my customers are always happy. Please can’t we just build for web and mobile and desktop and tablet?

Nope. For your MVP, building for one platform will help you in a myriad of ways.

It helps save development time and money
It reduces churn when you need to change or tweak features
It even allows you to focus your marketing for that initial launch only in places and with groups that will use the platform you’re on.

These sound like good things right? Not doing ALL the things IS a good thing. I promise.

Also, just because you launch with one platform doesn’t mean you’re barred from expanding for all time. If you have amazing demand, then this means you’ll also have more money and information from users to know where to go next (build that Android app! Add that desktop version!)

If you over build and were *gasp* maybe a teeny bit wrong about your users, then you have a big ol’ technical piece that is getting dusty, is underused, and is likely still costing your financial resources to maintain.

Don’t be this creepy, empty castle subdivision in Turkey.

If you feel pretty confident about knowing what your user’s want and where they are but still need help determining the technical solutions, we’re happy to help.

Send us an email (from an app OR a website! 😉 )

Feb

Design for Fat Fingers

Have you ever had this happen when using your phone?

You typed in a ton of things on a page and then go to tap the submit button and your finger accidentally hits another button or link nearby? Or you weren’t able to type in the fields to begin with because you couldn’t get the cursor to move to them?

Screens these days are getting large and we can technically show a ton of things on there…but the thing is…our fingers are the same size they’ve always been (and not all of us have tiny hands like Donny T.).

A rookie issue when getting started with mobile design is making your touch areas too small or crowding too many things in one spot. (You can infinitely scroll, which means you have infinite space so chiilllllll and space that stuff out PLZ!)

Making things hard to tap makes users frustrated, and when they’re frustrated, they don’t return. BYE YOU GIANT HAND PEOPLE! I DIDN’T WANT YOU SHOPPING ON MY APP ANYWAYS. (That’s probably not what you were going for, but that’s what they think.)

So what SHOULD you be doing when designing buttons for mobile apps?

Luckily for you, you don’t have to go around measuring the finger tips of all of your potential users. Apple and Android have determined the optimal tap targets for you.

Apple’s Human Interface Guidelines recommend a minimum 44 x 44 px area while Android recommends 48 x 48 dp* when designing buttons for mobile apps.
(Let’s not go into the px vs dp discussion today but here is some reading)

Now that’s a good starting point but those are MINIMUM requirements. Actually the average human finger pad is 10–14mm and the average fingertip is 8–10mm, which mean you should be shooting for more like a 57px touch target. This is also backed up by tons of research. Check out Fitt’s Law if you want a deep dive.

That’s pretty big. Is my screen just going to be giant buttons?

Don’t worry! While it is good to have a decent button size not only for tapping but also for legibility/accessibility, you don’t always have to give that much visual weight. You just need that much spacing around your tap area so that there is no overlap with another actionable item.

Image courtesy of Material Design Documentation

When starting your mobile design make sure to set up sufficient padding around all of your buttons using the specs above for the tap areas.

Happy tapping!

Jan

A new look

Oh hi! You miiiight have noticed that things are looking a bit different at the online mooncabin. We decided that we were long overdue for a facelift, since we’ve been rocking the same look since 2014. The outside was workable but the inside was a bit of a time warp. Plus in the past few years we’ve been itching to add some new content but couldn’t figure out how to cleanly implement it with the old template.

The old template

Our old website was a wordpress template implemented before the invention of “page builders”. The inside was a scary land of stacked shortcodes. We didn’t like touching it because each time it required diving back into learning the mystery pseudo-code that stitched everything together. The template ceased being supported a few years ago but at that time we were mid-mobile-dev-mania and didn’t have time to look into alternatives.

What next?

So here we are: 2019. Web development has totally evolved, search engines are now super fancy/picky, responsiveness is key. Even WordPress, itself, decided to undergo a bit of a renovation this year. We’ve built a few other websites in the meantime and it’s helped me have a better idea of what we want and don’t want. We still recognize that we are better mobile devs than web devs, so we weren’t looking to build anything too custom. I’ve test driven several different page builders in the past: Avada’s Fusion Builder, WP Bakery’s Visual Composer, and this newcomer Tatsu run by Brand Exponents. I really dig the interface for Tatsu – it marries flexibility with simplicity and since it’s relatively new, it isn’t saddled with a ton of baggage/backwards compatibility like the industry leaders so we went ahead and dug in. Several iterations later – I think we have our final result.

What’s new?

EVERYTHING! Just kidding. Some stuff is really familiar, because its true and it works, but we did want to revisit how we talk about our work. We added a huge section on our Process. Building mobile apps is still a new concept to many people and “how does all this work” is the #1 question we get from leads. Dumping an entire load of process on someone in an initial meeting can be somewhat overwhelming, so it’s nice to have a place that potential clients can check out at their own leisure. We have a new area that focuses on our internal projects, which will grow in the new year as we add new ideas and ship more.

In the meantime, keep checking in. We’ll keep adding and polishing in the upcoming months, but I wanted to go ahead and kick off 2019 with some fresh code. Hope you like what we’ve built thus far.

As a side note: There’s really only one ongoing debate to settle – ARE THERE ENOUGH SPACE PUNS ON THE SITE? (Wiley always thinks there should be more.)

Aug

Sifting your User Research

So last we left you we were meeting with every meetup or conference organizer in the Metro-Nashville area. And then I emailed some in San Francisco for good measure.

When we’d meet, I had a giant list of questions that I’d generally attempt to cover during our chat. If we veered off into an uncharted area, no problem, but I typically tried to cover some of the same topics with each and every person I spoke with so that later I could compare and contrast responses. After each meeting, I’d “brain dump” everything we talked about into a text document. At the end of this I had over 20 pages of “notes” from organizers here in Nashville.

Welcome to Jennifer’s crash course in user research….

Did everyone say the same thing? Nope.
Did everyone have exactly the same issues? Nope.
Did you really expect every single person, to have the exact same needs? Well, no…but that would definitely have made this easier.

So how do I take all of this broad feedback and use it to come up with meaningful answers?

First I looked for trends…

What is something I heard from more than 3 or 4 people? Something that kept coming up without my asking or prompting?
What was the response when broadly outlining my idea? Tepid, interested? People will rarely, if ever, ACTUALLY tell you they don’t like your idea. They’ll just…kind of nod and make noncommittal statements about the idea instead of discussing how they, themselves would use it.

Now what are the trends amongst the people who offered similar suggestions or had similar responses?

Is it one specific kind of person or kind of meetup/conference?
Are issues noticeably split amongst different groups?
Are these suggestions/trends actionable, solveable, and from large enough demographics?

I discovered that those who, in a previous life, held a job that required them to be more social didn’t have as hard of a time going out there, hitting the pavement, and offering the right information to potential sponsors. I also noticed that organizers who had been doing this for a while succeeded through trial and error, or through helping with other local efforts like tech conferences where more experienced people gave advice.

All of a sudden our market for organizers who needed help with how to ask for sponsorship was smaller. It was looking like just newbies and those whose core competency was more solely focused on code versus people .

But, I DID have one piece of feedback that came up over and over from this more experienced group – “Once we’ve used up our personal connections, we don’t know who specifically to ask to grow our sponsorship” …not what to ask, or how to ask but WHO.

This was different from our initial assumption. (And why you do this process to begin with). And this isn’t feedback that we can easily solve with a simple solution. Which makes sense—usually the hardest problems are the most prickly. After some internal discussion we did determine that there were a few potential ways to tackle the “who to talk to” problem but none of them are super easy.

So now what?

We have to ask ourselves, can our potential product not only provide help to those with the “how to ask” problem (early stage meetup organizers), but begin to seed data and insights for those organizer-pros who have trouble with the “who to ask” part (veteran meetup organizers and larger conferences). Will our actual “value” be on the back end of the product and not where we initially thought?

In assessing your own user research ask yourself:

Are there still problems I can solve?
Can we still reach users with these pain points?
Is this still profitable? (Are there enough users with this pain point, is the solution reasonable to build, and will those users pay for it?)

For us, it’s time to go back to the business model and adjust our numbers. If not as many people are within our initial demo or willing to pay for the proposal product, can we get enough users in there to build data for a sponsorship leads product which seems more valuable to experienced organizers?

Next steps? We’ll attempt to broadly scope and estimate features for supporting the two types of users in order the reach profitability instead of just one. We’ll need to talk with organizers again now that we have firmer features in mind. And we should put some infrastructure out there to test the interest beyond Nashville (Product Hunt, Beta List, etc).

Aug

Testing the Waters – A New Product Idea

So you know how we were trying to “magic” an amazing idea last month? We made lists. We read books. We drew on the white board a lot. We looked at everything from Product Hunt, Beta List, and YCombinator. I even scrolled way back in the @BoredElonMusk Twitter handle (There are some great product ideas in there…that we’re not interested in building).

Well after weeks of being super negative about everything and thinking that we were never going to find anything good, we went on vacation to NYC. Then I went on a walk to lunch – gotta get my Turnip Truck Hot Bar fix – and I had an idea….

We host Nashville Cocoaheads. They have their meetings at our office. Sometimes we buy pizza or beer for them. One of their challenges has been finding sponsors. Mostly because they’re busy with their day jobs, not to mention sourcing the actual speaker part of the events. And this isn’t the only group. We’ve also had emails from friends who needed money for chairs for their usergroup. Like, a lot of chairs. Their event is super successful, hundreds of attendees successful, but we still ended up sitting on the floor one time. (We did give money for chairs the time we were asked and now they have amazing venue sponsors who have their own chairs).

This sucks.

My friends are trying to create wonderful things for their peers and shouldn’t be worrying about these small things. We’re sitting on the floor. Or drinking water instead of beer. Or rushing from the meetup to dinner because the organizer only bought 2 pizzas instead of 6 because they were paying for it out of pocket and now it’s 8pm and I’m super hongry.

Now I know the point of usergroups is not pizza…or chairs. But these things help. You’re tired at the end of the day, and you’re taking that little bit of energy left to go to a thing and learn something new. It would be nice if there was sustenance there, or even better…free tickets to a conference or a free pass to a new software tool. Congratulations on doing something extra – here’s another piece of help.

So, I got to thinking…wouldn’t it be awesome if there was a tool to help my friends find sponsors for their usergroups quickly and easily? They wouldn’t have to cold email. They wouldn’t have to figure out how to make a pdf with their sponsorship packages when what they care about most is being a really good software developer. They wouldn’t have to buy the pizza themselves or email their friends for help (even though we like to help).

But wait….

is this a real problem? Or are my friends just bad at organizing meetups?

So I sent quick emails to friends who are organizers along the lines of “What do you think about a sponsorship tool for usergroups…” I got responses back that were practically epistolary novels about how YES. YES WE WANT THIS. OH GOD. YES. and then 1,000 ideas of what it could look like.

Well then….let’s proceed.

So I wrote some more emails… a ton of emails actually. And I had coffee, and beers, and Slack convos. And… it seems like a problem a lot of organizers have. Maybe not always on the same dire level but it’s still a task no one likes but everyone needs.

Sidebar: I LOVE OUR LOCAL TECH SCENE and how amazingly patient and helpful all of the Nashville organizers and sponsors are. You guys make me want to build this thing immediately, if only to give back to those who have already given Nashville so much.

Currently, I’m still in the process of having meetings with the Sponsor side of the equation but I’m looking forward to it.

I think we might have found a winner you guys. We’re passionate about our local tech community (and other ones like it), this is something within our grasp to build (sorry, massive email sentiment analysis idea), and maybe just maybe it can be profitable (sponsorship help for podcasts, for school clubs, for little league teams, for any grassroots organizer of anything).

Next up. More meetings. Competitive Research. TAM and monetization. What does this idea look like in feature form? We’ll keep you posted.

Apr

Let it go – Building a real MVP

In Startupland, the most valuable product is the Minimum Viable Product (MVP). Why? Because you didn’t blow your entire budget/savings getting there.

People often come in and start throwing this term around “MVP”. Requesting something along the lines of: iOS and Android apps, a web portal, and a full dashboard for all users and grandma! Oh and an admin portal with state of the art features as well.

This is not an MVP. This is your wish list. Your nice to have list. Your 2 years in list.

“But…but… I NEED to have these things or I won’t be successful.” you say.

Hogwash. Success is based on building the RIGHT thing. Not ALL the things. I know it’s exciting to start building but slow your roll!

While it’s not too hard to trim an initial feature list down by pairing some low hanging fruit, oftentimes you’re still not at your target budget. You may need to drastically slash costs to get to market or not get there at all. At this point we’re not talking about removing 2 questions from the signup page or changing out how fancy search is, we’re talking about removing entire areas or better yet – entire platforms.

Prove your business model before investing in it in multiple tech stacks.

Do you rrrrreally need that admin portal for your 25 users? Can you hold off on Android to see if what you have in iOS is really what users want? Do users really need to have both web and mobile access?

What should I cut when I don’t want to let go?

1. Assess features & users to find platform launch targets

Where are your users hanging out? Are they older? Younger? Are they turning to the web for this service? Is this something they need on the go? Assess your audience and the core features of your product to determine whether this is a web or mobile play to start (you can add more entry points later! This isn’t forever!)

2. Sweat Equity for Behind the Scenes

Even the great and powerful OZ understood the value of manual effort.

Do you really need all the management stuff automated? Weigh your time versus your cost of development. Is hiring a $10 an hour intern to review applicant profiles cheaper than building a machine learning service? Can you keep track and manage payments with excel and quickbooks instead of a custom point of sale system? Only upgrade/build your tools when the workload demands it not before.

3. Tech debt can be your friend (in the beginning)

Don’t polish and deeply invest in a feature if it isn’t proven yet. High traffic areas can be improved upon once their value is clear. What if you spend half your budget on a feature that when launched collects cobwebs from your so-called target audience? Make pivoting painless with lightweight development decisions.

Infinite runway? A budget as deep as the Grand Canyon? You may not have the make these hard choices, but I would still advise you to do so. It’s healthier for a product to be able to grow based on real world user experience. Give yourself the flexibility to change features and change messaging without having to visit 6 different codebases and remove 8 months of work. A simple product launch isn’t easy or straightforward, but it’s a smart one to start with.

Still having a hard time slimming your MVP? We’re here to help! We love creating products that built for success and don’t have a problem saying no (or strongly judging you for not being able to say no to yourself).

Need someone to question all your decisions and make helpful suggestions?

Jan

Is Your App Idea Special?

Let’s be honest – app ideas are hard. The world is big and fast-moving and what’s hip today might flop tomorrow. Having what feels like a good app idea is only the first small step in building a successful product.

The Process

So, imagine you’ve dreamt up a great new app idea, what should you do? The very first thing any entrepreneur should do is check if their idea already exists, but not for the reasons you might think.

You’re not looking to see whether the door is shut in your face, you’re looking to see if the idea has potential in the market. Most app ideas are not purely original. Tons of people are having the same great idea each and every day. But that’s okay! Other people with similar ideas prove that it is a good one! Seeing competitors shows that there is a need and it is feasible concept.

Realistically, you ARE going to find a few apps that do some similar behavior to what you’re imagining. Whether those apps are wildly successful or quietly unnoticed, you’ll have to innovate and find ways to improve upon these existing products. Think about features that are missing, designs that can be improved, and new ways to monetize. Do you think this market has room for another app? How can you attract the most attention?

What if you go app hunting and can’t find anything even close to your app idea? In this scenario, your app idea typically falls into one of three cases:

Your app idea is original and nobody else has thought of it
Your app idea has been discovered to be too costly to develop
Your app idea isn’t appealing to enough users

Naturally, you want to be in the first category, but what if you’re not? This is hard, and you’ll likely need to reach out to potential users and gauge their interest. Continuing down this path is certainly risky but can still be very successful.

The Bottom Line

The harsh reality is that most app ideas are uphill climbs. You’ll work, you’ll iterate, you’ll advertise, and sometimes you’ll fail. Failure is a tough pill to swallow, but it’s a fantastic learning opportunity. Did you make a mistake when assessing the viability of your idea? Did market conditions change? Or did someone else beat you to the market while you were developing? No matter the outcome, use this experience to craft your next great app idea.

Oct

A Brand New Android Studio – 3.0!

There are few events in life that give developers such bliss and excitement as when their favorite tools receive a healthy refresher. Earlier this week the kind and hard-working folks over at Google released the official version of their long-awaited upgrade to Android Studio. It wasn’t an unusually long wait (Google seems to release new major versions roughly every 6 months), but the anticipation of diving into its new features has kept me watching Android Studio’s Stable Channel for months.

In the events leading up to Google I/O in May, the Android Studio team had teased the community with some incredible new features for Android Studio 2.4. Many developers, myself included, had our collective fingers crossed for a surprise release at the event and were shocked when Google announced official support for Kotlin in Android development. Additionally, they boldly nixed the 2.4 version of Android Studio from existence, bumped to a clean version 3.0, and continued pushing out numerous betas and release candidates. Now, many moons later, we’re blessed with a well-tested and feature-packed development environment ready for production use.

Without any further ado, let’s talk about some of those new features.

Kotlin

A few years ago, Kotlin burst onto the Android scene and was met with both praise and skepticism. JVM languages like Kotlin aren’t uncommon and most aren’t well suited for Android development (with the notable exception of Groovy, which Gradle uses). However, continued Kotlin development attracted more and more followers. Plugins were made for Android Studio and soon Kotlin became a common concept for cutting edge developers. Google must have been keeping its eye on Kotlin as well, and for the first time in Android’s history, Google announced full first-party support for another programming language to sit alongside Java (ignoring the NDK, since Google most certainly does!). Kotlin’s concise syntax shares similarity with numerous other languages, notable Swift, Apple’s preferred iOS and Mac OS development language. It addresses numerous Java shortcomings such as null safety, a lack of class extension functions, and easy threading support via coroutines. The full list of Kotlin features is long and you can read about them here!

Java

On the topic of languages, Java got some love this time around as well. For a multitude of reasons, Android’s Java doesn’t always have the same functionality as the base language. One of the most common criticisms of Java is its verbosity, especially with anonymous classes. You know, the ones you make to implement callback interfaces like View.OnClickListener. Java introduced support for lambda expressions, which are essentially abbreviated functions to reduce repetitive boilerplate code, in Java 8. However, Android struggled to provide support for lambda expressions; you had to use the experimental (okay, buggy) Jack toolchain or the 3rd party Retrolambda library. Finally, Android developers can use natively-supported lambda expressions. This is a huge plus for libraries like RxJava which rely on numerous single-method interfaces, making them prime candidates for lambda expressions and drastically reducing code length.

Android Studio

The last new piece I’ll talk about is an upgrade to Android Studio itself. For as long as I can remember, I’ve been using the Android Device Monitor to profile the performance of my apps. It was a little ugly and a little hard to use, but it got the job done. Google used its magic and transformed it into the Android Profiler. Earning a proud place next to the Build and Stop buttons, the Android Profiler button opens CPU, memory, and network monitors right within the Android Studio window and sits nicely next to Logcat and your other bottom toolbar menus. You can monitor performance, view payload information, find laggy parts of your apps, admire the very pretty interface this amazing suite sits within, and more. I’m eagerly looking forward to testing my apps and improving my code using these upgraded profiling tools.

I could go on but instead you should go download the new version of Android Studio yourself and play around!

12 3 4 5