• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for May 2014

Your native app can be a platform

May 16, 2014 Leave a Comment

The pendulum of Web vs. native technology continues to swing, and this is a good thing

My favorite topic, “Web vs. Apps”. Why do we keep coming back to it? Because it is important, because there is an itch, because there are trade offs, because you can choose either to do the job, and whenever you do something new you have to revisit your assumptions and how they will affect your choices this time.

There is a scale of native to Web (or other non-native platforms). It is rare to find any application that is purely on one side or the other. Again, to set the context, we are talking about how you build your apps that will be delivered through an app store here, ignoring benefits of having a Web presence (although pros and cons will tie into how much you need that presence AND how different it should be from the native apps).

Web technology can deliver more and more

DHH talked about the sweet spot of native navigation with web content within. The Web stack has gotten better, both due to software upgrades (e.g. ChromeWebView) as well as the fact that phones keep getting faster on the hardware side.

It is important to acknowledge where DHH is coming from too. His heart comes from a server rendered web application place. A lover of Ruby. Interestingly, a year ago, we were hearing someone else talk about how they could use their beloved Ruby and still be native, when Nick Quaranto posted about the RubyMotion built Basecamp application. The new Basecamp hybrid app doesn’t even have the shell with RubyMotion:

“our next gen is pure ObjC. We decided to dig in and learn the platform as a team.”

Interesting.

What about the UX?

On the one hand the Basecamp UX is relatively simple. If the team isn’t looking to add some crazy components that can only be done in a native manner, then it can be a good choice to take the approach they have.

At the same time, iOS applications have broken free from the “wow they all look the same” of early years. Over time teams have worked out how to make the applications fit the platform while still having appropriate custom feel to them too.

This opens the door for “well if we need to build a custom UI and controls we can choose which stack to do that in”. There is the flip side too though. Some of the best applications make dramatic use of the native device capabilities, and you can build dramatic effects on native that you can still not even get CLOSE too using Web Technology.

This will always be the case, and that is why if you build something that is just wrapping one WebView, you are closing the door to that world.

The original Facebook app was somewhat reproduced with web technology by Sencha, but how about Paper? Maybe you can get there (Famous does a solid job), but there are some things that you need all of the performance available to you to pull off well.

Choice

DHH talks about the paradox of choice, and how people like choices more than they like to choose. That is true and very real, and is something that the Web has made frustrating. There are so many choices and the lack of a component model meant that you were backed into corners for so long. We are seeing some progress there with W3C Components and the like.

There are some pieces of “good” that come with choice though. The Web, even with its constraints, have allowed a massive diversity. With that diversity comes evolution. This can be a match made in heaven if the platform is watching and the diversity spurs the platform to also evolve and raise the bar. The host assumes, speeds up, and grants new abilities and potential allowing the parasites to use the host for things that they were doing, and take their effort to build more.

This is why good architecture lets you put off decisions for as long as possible. The minute you are backed into a corner, your fate may be sealed and you can die in a small box.

Your app is also a platform

The great ability of the native application is that it has code preinstalled (since the user had to install it) and it has hooks and permissions to a lower level than a general purpose environment (the browser).

Your application, or a set of applications, can together make a great host for other native and Web based code. You can build a native customer scanner, and setup a simple way for a web view within the application to call it, get data from it, and come back.

On a case by case basis you can choice for parts and pieces to be Web or native. You can A/B test between them…. try some new things via Web because it can update without going through the store. Your configuration service and various APIs can send down events that can be rendered in different ways.

The Facebook news feed is a great example of this. Imagine an array of JSON that comes down with different message types. The controller can say:

“Hey, do I have a native view that can display this type?”

If not, you can render it via the Web.

Organizational Change

The pendulum is always swinging, and it is at a different point based on what you are trying to build, and the people you have to build it.

One of the huge challenges that I am seeing in larger companies is the switch to thinking about a holistic customer.

I have seen variations on this time and time again:

  • “Crap, we need a mobile team to build a mobile app!”
  • “We have built feature X for desktop, mobile team can you implement it now?”
  • “Our mobile and Web experiences are too disjointed”
  • “Let’s try to ship mobile and Web experiences at the same time!”
  • “Let’s build vertical teams that can deliver mobile and Web”
  • “Let’s plan products for people, and not think of one platform ‘first’”.

Huge organizational changes are happening to align this thinking. Teams are working out how to work. We had a bit of a golden era of simplicity when you just had to build a web experience (very simplified… many companies have had to build customer centric experiences to various form factors… TV, kiosks, etc) and we are growing our chops around how to make us deliver better solutions for our customers.

So, the pendulum keeps swinging, and this is in fact a good thing. It means that there is choice. It means that you can choose what fits for you. It means that you can make changes over time.

Thoughts on App Links

May 1, 2014 Leave a Comment

Some initial thoughts on app links in general and on the Facebook solution

When I heard that Facebook was throwing their hat in the ring with a solution to app linking I have to admit that I was excited and concerned at the same time.

On the one hand I have a skeptical side to the incentives of Facebook. I had just seen Mark talk about how the silos of Android and iOS were bad and that we should use the Facebook meta “platform”. This felt a touch cheeky when you think about how in many ways Facebook is an incredible silo.

On the other, there is a problem to solve. The URL is an amazing feature of the Web, and the app platforms need to have a way to meet with the goodness that the loose coupling of that mechanism provides.

I have personally found that all of these situations can be true after tapping on a link inside an application:

  • “I have the app installed and I prefer it, why are you showing me this janky web page!”
  • “Don’t tell me about your app! I just want to view the darn content!”
  • “Don’t render this in a WebView with your janky wrapper, just open this in my browser of choice please”
  • “Ugh, I don’t want that app to handle this, I wish it would open another one!”

There are a few different pieces to the puzzle that I would love to have more control over, both as a developer and as a user:

  • The platform should be able to cater for as fine grain deep-linking as possible
  • As a developer, if I am integrating with a known service, I would love to easily find documentation on the API available to get into the app (e.g. the custom URL scheme)
  • As a developer, I would love to have a registry of apps so I can search for options
  • If my application opens any old URL (e.g. not something I am custom dealing with) it would be nice to be able to have the option for app vs. web
  • As a developer, I would love to easily give the user the choice on how to handle an action (e.g. on iOS if they have Chrome installed, offer that as a choice along with Safari)
  • As a developer, I would love to be able to monetize through an affiliate program

User First

Mark also talked about how the end user was the number one customer for Facebook. To that end, I would love to empower the user more than we currently do.

I think that there is a missed opportunity with app linking to enable just that. One of the great features of the Intent system on Android is that we have a level of abstraction that is better than the default one on the Web. How many links are there on the Web to URLs such as:

https://www.google.com/maps/place/Palo+Alto,+CA/@37.42565,-122.13535,12z/data=!3m1!4b1!4m2!3m1!1s0x808fb07b9dba1c39:0xe1ff55235f576cf

What if an amazing new mapping company came on the scene. It would be awesome to be able to take over those URLs and use that service. I guess I could install a plugin to try to change the URLs, or I could hijack as a service, but if I could instead map (pun intended) a general URL scheme to a location and then have the user select what application or service can deal with it, then we are open for business.

We can then think of “actions” and map to those, and we have a level of indirection. We wouldn’t have the frustrating “attach file, attach from dropbox, attach from …” that we get today. One application can say “I need a file from the user” and the system can detect any options and the user can choose what to do from there.

iOS doesn’t have good support for this now, but maybe the “App Linker Alliance” could have come with a helper experience that would enable just that. It would do the detection. It would save the defaults. If the user doesn’t want to launch “the app” it would go to the web site instead, etc.

Being able to hit a http URL and look for meta data is great and covers some nice use cases. It would also be nice to have a really good registry (nicer than http://graph.facebook.com/?ids=http://hulu.com&type=al? I don’t want to have an OAuth key do I?).

In some cases I wouldn’t mind being able to say:

For http://foo.com use foo:[passing in the full url]

and the app deals with it all. A nice cover-all. With the right registry and handshake maybe we could do more to ensure that only the “official” registered app is getting the info, so we don’t run into a “first app to define that URL scheme wins” type scenario.

Markup is great, but I would also love to have a /applinks.json type option that lists it all etc. I need to think deeper on this.

With WWDC coming up next, I am very curious to see where Apple takes deep linking and cross application communication. They have punted on what they had built a couple times (allegedly) but it is surely time.

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • Horizertical: Should you focus horizontally or vertically as a platform?
  • Taste and Nutrition on the Web
  • Working on our Web Vitals together
  • Die, Print Layout, Die…. the Chrome Extension
  • Browsing the Web while watching it’s vitals

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Relations Developers Development Distributed Teams Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future Gender Equality Google Google Developer Google IO Habits Health HR JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2021 · Log in