Mobilism 2012 aantekeningen
Peter / Sjoerd
Horace Didiu - asymco
Commerce analogy to warfare
Mobile phone market still dominated by non apple phones?
Samsung leading in units shipped, apple leading in revenue and profit
Device brand vs developer brand: this is the API, instead of this is the device
Rovio (angry birds) more worth than Nokia
A-Symmetric competition when entering the market
Finding new jobs to be done
Segment accordingly, solve the problems you find
Perspective app pixxa
”Establishing something new is easier than changing a running business”
**Horace Dediu **
@asymco
asymco.com / pixxa.com
Only 5 years ago completely different playing field of mobile phone companies. Rise of the “Davids” Apple/HTC vs “Goliaths” Nokia/Motorola. Now 2012 Samsung overtook Nokia and Apple #3.
This was volumes, now revenues… starts out ver similar. 2012 shows #1 Apple, #2 Samsung, both almost triple the revenue of Nokia. But for profits… Only Apple and Samsung have huge prfits, while Nokia, Motorola & RIM actually losses. Apple has 73% of the profit share of the overall profit across companies, Samsung 26%
Now for the analysts. Did anyone predict this rise of Apple? Professional analysts have a margin error between -10 and -30. Over time more analysts appear, and it seems the amateurs are less error prone and more positive. Professional analysts consistently under-expect performance of Apple.
Rovio (maker of Angry Birds) is going IPO and is now overtaking Nokia in market revenue/share
According to Dediu big companies should be thinking about platforms instead of hardware. ??
@brad_frost: “The mobile industry changed from a device business into a system business. Platforms and APIs now trump devices themselves @asymco mobilism”
Learnings from David/Goliath: look for asymmetric competition, so the competition does not (know how to) respond.
New Nokia developments are not a threat to Apple. @brad_frost: “True disruption requires abandoning “iPhone killer” pipe dreams. Going head-to-head won’t truly drive innovation. @asymco mobilism”
Study the needs of the user and not of the market. Segment the market accordingly.
Ppk the mobile platform world
Owning the stack: apple and rim control browser os and device.
Elaborate dissection on how and why device manufacturers have not dropped android in favor of webos, tizan, bada, windows phone, meego, Mozilla
Peter Paul Koch
@ppk
Handing out various goodies… (sponsored)
The Stack: Browser/OS/Device. Two players own the entire stack, Apple & RIM. Google & Windows just own Browser & OS. The devices under this are divide between a plethora of hardware manufacturers.
”Consumers don’t care about the device, they care about the OS/UI.”
Nokia is the odd one out, having a few of their own OSes. Used to be S40/Symbian using the same browser tech, then migrating to MeeGo for smartphones at the end of 2010. in 2011 Nokia ditched MeeGo for Windows, all the time still also using S40 for feature phones (low-cost markets). Windows being used by Nokia led to other device manufacturers losing interest in Windows. Then in 2011 Google bought Motorola. Curious to see the other vendors’ response, since this could mean unfair advantage to motorola. What now? PPK expected Android to take a dive. Now going into why this did NOT happen. So what are the alternatives? WebOs had a solid UI that could stand up to iOS but lousy technology base. MeeGo rebranded to Tizen. It’s ging tobe HTML5 based so it looks promising. Samsung also invested in Bada. Now recently Bada was open sourced, most recent rumors are Bada will integrate with Tizen. Other options then? Yes. BootToGecko (Mozilla). Running a complete HTML5 OS running on top of Android technology as a base. But Mozilla did not partner with device vendor but a mobile operator in Brazil, telefonica. First targeting low-cost market. All these alternatives are not really viable. So the device vendors have to resort still to Android as an OS in most cases.
But wait, we’re missing a layer. The CONNECTION! This is where we need the operators. Operators subsidise devices, in most markets. Resulting from this is another layer at the top of the stack: Sales. Subsidised phones mean that operators virtually own the market. Operators push Android. Not iPhones, because there’s no influence on that. Operators like to meddle with the browser and OS layers. Just because they can. Wh don’t they push Windows phones? Two theories. Skype was bought by Microsoft and this means free phone calls. This is something operators hate. The other is support calls. Operators supposedly like android better because it generates less support calls. These are both just theories, but the fact is that operators favor Android.
Opera profits from this. They cater to the meddling of the operators with opera mini for example.
Apple is competing with the operators in the Sales layer.
James Pearce - Facebook
The mobile experiences are happening in native apps. Not on the web apps → web overwhelmed by the comfortable native ecosystems.
Future: discovery distribution monetization
Facebook offers their web ecosystem for your web app, through Facebook AppStore
Standardization implementation
James Pearce (facebook)
@jamespearce
All the exciting stuff is not happening on the web, but on the native stack. So is the web dead? Web had potential of becoming the first class app of the iPhone. It didn’t, and apps filled the gap.
Web is all about search. Which is optimised for documents, keywords, etc. Not Apps. There’s no ownership for web apps. No rating mechanisms, no monetization, short of adveritising. In the meantime the web as a whole ahs evolved from being document centric to social, personalised experiences. It’s grown into a push based web (reccommendations, social media, etc). Facebook is the prime example for this. All technology is very simple (games, pictures) but very strong on social. So how can we do this for mobile web apps?
Segway into Open Graph. Enables any web page to become a rich object in a social graph. Oh yeah and there’s also facebook apps now. (totally irrelevant to this talk however).
Standardization is nice, but implementation speeds vary so much that standardization is severely lagging and impaired, leading to fragmentation. Which is permanent. There’s always new non-standardised features on the horizon, moving towards standardization at a snail’s pace. The pain is in the ‘almost standardized’ features. These work almost everywhere, but not quite the same. Ugh. We can change that, according to Pearce: collaborating on the Core Mobile Web Platform Working group → http://coremob.org
Web apps not being able to access phone features, are not apps at all. Let’s make browser vendors aware of that. Graceful degradation and progressive enhancement just hide this, the’re hacks not fixes.
Ringmark is the acid test of mobile browsers, testing for support of features already available in native apps but often not yet in browsers.
Device APIs are needed for the enabling of web apps that interact with devices services/hardware. Geolocation is an example of something already woring in many mobile browsers.
Web photosharing app PoC on bit.ly/gumsto (only works with opera12 on android). only 100 lines of code.
Shout out to BootToGecko, col stuff on the horizon. Lots of ideas for the api there.
Biggest challenge you face is yourself. Oversimplify and everyting’s easy. For instance max width 320px; But us e the broad view of all DEVICE capabilities and innovate, take advantage of these. Don’t oversimplify, but think of the user and what you can do with the movile capabilities to help the user live their mobile lives better. “It depends” isn’t good enough.
If the web is dying, it’s the document based web. Not the social, innovative, mobile device-features-accessing web.
Laurent hasson
Say no to NIBS native is better syndrome
Goals: single page interface
State management, back navigation, chrome → webintentsvas well!
Browser events → browser and app fighting over mouse / touch events
Viewport → abstract pixels, zooming and panning screws up 1 to 1 pixels → deal with %
Greg Schichter on web apps
App vs Site: Users are conditioned to the app life cycle. But htey don’t actually care if it’s native code or web. So why not use web technologies for the job?
Apache cordova is the new open source PhoneGap
Say no to NIBS. The web scales almost infinitely and is cross platform and skills are abundant. The web is not better than native, but absolutely comepetetive.
Design Goals: Single page app metaphor, Lack of browser chrome, browser evetns, viewport management.
Viewport: a pixel is no longer a pixel. Desktop viewport is straightforward. Mobile, not so much. Panning, zooming, the viewport is just part of the accessible canvas. So pixels are no longer display-relevant.
CSS Pixels. On mobile, these don’t exist, really. 1 pixel is not 1 pixel. Very different in different devices.
Same goes for screen.width etc. Set your viewport met tag to all fixed. then use percentages. Use media queries.
Check for landscape and portrait mode.
Touch events. Some do touch well. others trigger click events on touch. Inconsistent preventDefault() behaviour.
Need to be able to discern between touch/zoom/pinch etc and ‘desktop clicks’. Blackberry has a meta tag to just skip native ui and convert touch to click directly.
…. more hacks, turn off user-select in css by setting to none.
Kevin whinnery - appcelerator
We’ve got one platform, both sides are right
Web is open, free and portable
Native is first class citizen and more responsive
All platforms have their strengths → right platform for right app
Igor Faletski - Client Side Adaptation with Mobify.JS
@igorskee
Mobify.js is about adapting stuff, not having a completely different thing. MIT0icensed JS toolkit. Popular with e-commerce, publishing, enterprise.
Why? Most of web is made for desktop, but accessed more and more though desknots. Fragmentation server side is far worse. both are growing. Web developers are poorly equipped when it comes to mobile/iPad work. No decent frameworks, except for?
Started out with Mobify studio. A web app to make custom css for parts of your desktop site, hosted at the m. subdomain. Now we aim for just one url.
One of the problems is that it takes 200% of the effort for 20% of the traffic. Develpers get locked in perfectionism syndrome, waiting for better times.
This all resulted in Mobify.js
Uses a script tag directly after the <head> to bootstrap a site for Mobify. then download the local tools to develop. Use web interface (GUI) to select key features you need to Mobify (keep for your mobile site). Develop your mobile site offline, then push the file to the previous javascript and it just works.
Multichannel control over your website for any device. Universally compatible, one site (diff. solution from hippo channels), repsonsive images and scripts. ONE url for all devices.
Not just adapting existing content/solutions, but also replacing with other content/solutions, without any redirects.
Re-using existing content makes for faster development cycles. Because it’s pure front end, it works with any back end. Can be combined with other JS frameworks.
ROI? Mobile websites generally increase conversion rates by 2.5x, revenues on mobile commerce doubled, average order sizes also larger.Customer lifetime value increases as you support all media.
With no mobile, you miss out on all mobile marketing, search, facebook sources etc. Also, SEO is influenced by mobility more and more.
Security: cleint side adaptation doesn’t impair (change) your server security.
Seperate experience for tablets, like more advanced touch features but more screen estate. Still on the same url, with the same content base.
Griggs - smart tv
Browsers not bad, experience is
Multiscreen world
Auto play vs hit your dataplan
Jquery ui library
Just thinking about resolution is not the way the way to create a good UX
Jason Grigsby - The Immobile Web
@grigs
See twitter (autotweeting), Slides at bit.ly/immobilism
Heiko Behrens
@HBehrens
Smartphones are everywhere and have great computational power.
Full webb apps can do some interesting stuff already, but big drawbacks, as discussed by others as well.
Hybrid apps: a native shell which cherry picks html where it can.
Scott Jenson - frog - moBile apps must die?
Default thinking : use new tech to do things we did before.
Perspective shift
”I can’t be bothered” website product store apps
Value>pain
Triumph of the mundane
Jit interaction → single use
Kuhn cycle book
How do we get beyond mobile
Scott Jensen
@scottjensen
Apps must die.
Trends:
app glut. Every thing has an app.
Fundamental ux principle: value beats pain. But both are very important. Often too much focus on value. Trivial things become doable if very easy. Triumph of the mundane.
Trend2: size and cost reduction: zombie apocalypse of smart devices.
Trend3: devices leverage other platforms.
Combine these trends: xplosion. As more and more stuff gets smart, we get more and more apps. But we don’t want to install apps for one time interactions.
Me: use qr code to launch a web app?
Kuhn cycle (science theory)
We can’t keep on imitating native apps, but play to webs strengths. Look for micro functionality.
Liberated interactivity: free the interactive soul of a smart device.
Break out of the browser ghetto.
Discovery service, kind of local search. See all nearby smart devices.
Me: what about the overload?
B2g & tizen will fail if they just go head on with iOS.
Idea: wifi ‘qr codes’
Power to the people
Stephan Hay - responsive workflow
Every website has content
Cntent minded design
Design in text
Information architecture
Interaction design → simplify wireframes
Mash between interaction and visual designers
Design is not decoration!
Content inventory
Content reference wireframes
Designing in text
linear design
Breakpoint graph
Design various break points
Design HTML prototype
Presentation psychology → show screenshots
Design style guide
Pandoc? Text to HTML
Stephen Hay - Workflow in responsive web deveopment.
First discusses what happens when design changes need to be made in a PSD file. Needs a lot work for small changes. Especially the case if you need to make a few different sizes, like for mobile, etc. So Photoshop was good for single page websites, but also create too high expectations.
Answer: Design from the bottom up, so from the CONTENT out. So content & form are both important and should be chosen carefully, together. Choices based on technology are bad.
Essentially, think about what the message that needs to be communicated (i.e. if you just had unstyled HTML)
We are all interaction designers. Every choice you make influences interaction. Visual is about solving problems. Not just colouring in the UX design. IxD and VD should be fully integrated.
Responsive Workflow:
-
Content Inventory
-
Content Reference Wireframes: schematic division of content on the page. Structural hierarchy, w/o any content, just numbers mapping to a numbered list of content items found in 1.
-
Designing in Text: envisioning structured content using markdown, then converted to html (using pandoc)
“The world’s first website is almost mobile-ready. Structured content is portable to future platforms.”
-
Linear “Design” The bare essentials. Design your structured content.
-
Breakpoint graphs: mapping out widths and capabilities to designs (breakpoints/device classes).
-
Design for various breakpoints. Don’t forget to sketch. Sketch in HTML.
-
Not delivering PSD, so what do we deliver? HTML/CSS/JS prototype.
8 & 9. Presentation Psychology: For the first presentation use screenshots. Second time, repeat.
- Document for production: Style Guides! Inspired by @adactio’s Pattern Primer. Dexy.it is a documentation system. also check out Phantom.js/Casper
Remy Sharp - debugging mobile web
1 know thy enemy
Test cases js jsfiddle, modernizr
2 closing the gap
Local tunnel , fiddler,
@rem | http://speakerdeck.com/u/rem/p/mobile-debugging
At of debugging: Replicate, Isolate, Eliminate.
1. Know thy enemy
Use Emulators (mobilexweb.com/emulators) as a starting point., but real devices are king. Share devices. Investigate device capabilities using jsconsole.com?this
Understand performance. Example: lazy load JS, instead of having it all parsed on page load.
Get a grip on network monitoring. Use a proxy app like Charles or Fiddler (windows only)
Make test cases, use JSFiddle.net and JSBin.com
2. Debug
Host Locally (for vm’s, use localtunnel to be able to access webhost inside VM)
JS debuggig, for instance iOS Safari debugging mode. But it’s IE6 days all over again (lo-fi) Better: use jsconsole:listen. Or Weinre. Or Adobe Shadow. iWebInspector remotely debugging. Aardwolf; Add JS breakpoints, view values of variables, etc. Also check iWebinspector by @firt for debugging w/ emulator.
Next up, actual chrome on android debugging. BB playbook has full remote wireless debugging on port :1337 Opera has remote debugging also, and firefox mobile is coming out with it soon. So what about iOS? Maybe in iOS 5.2?
Build your own tools, like Remote-tilt.com
3. Expect the unexpected
Wifi != network operator! tethering your desktop can be a way to test this.
Last resort debugging: 50/50
Emulate slow connections. Various tools out there.
Beware of red herrings.
Seb lee deslile
Creative coding
PixelPhones
Smart algorythms for identifying the phones, cool game Nyancatch.
Jake Archibald - appcache
Appcache is good, but still needs some improvements
https://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag
Brad frost - Future friend.ly
Focus on content
Embrace the squishiness
Responsive is not about resolutions but about flexibility and futureproofness
New mobile site is an opportunity to create a new responsive website platform
@brad_frost
Rule #1: Create relevant, purposeful content.
Get your content ready t go anywhere, because it is going to go everywhere.
Context is fuzzy: both quantitative & qualitative.
More relevant content, more relevant contexts.
Responsive is not just squishing a smaller site. “Responsiveness is a characteristic”
Users don’t give a shit about the tech… They do give a shit when they are cock-blocked and can’t do things they wan’t to do.
Responsive web design is simply a great step in the right direction. Not a panacea. “Embrace the squishiness”
Start with mobile first… (note that this is the exact opposite of mobify.js idea).
HTML → CSS → JS
Separate sites don’t scale. But we can use these small sites as a seed from which to grow a nice, responsive new shiny site that one day an replace the old dusty desktop site.
When You’re Finished Changing, you’re finished.
Extreme pragmatism!
Liza danger - content
Over structure simple content
Important to think about structuring our content in a future friendly way.
Write markdown code without distractions, with metadata to help the HTML converter
@lyzadanger
Markdown! (then translate to html using pandoc)
Content First!
NPR’s COPE (Create Once, Publish Everywhere)
Be Mindful. Write semantic HTML, have design serve content instead of other way around. There is no silver bullet (especially beware of proprietary ones)
Future-flexible..
Brian fling - mobile design
Anthropology → honesty, usefulness etc for all audiences
Technology → 10 kinds of apps from plaincontent to full native
Design → user testing, crazy ideas combined with structured clean content
@fling
Technology / Anthropology / Design
| annabotsvine
10 types sites: 1. Mobile site 2. Desktop site 3. Responsive 4. desktop web app 5 HTML5 app mobilism http://t.co/WM1B3t4n |
| annabotsvine
5. Responsive web app (bootstrap) 6. Html5 hybrid app (Adobe creative cloud, phonegap) 7. Native hybrid app (facebook, linkedin) mobilism |
| annabotsvine
9. Native app 10. Universal app ( 1 app across different devices: ipad, iPhone ) mobilism |
Objectified doc > Kijken! hier bijvoorbeeld: http://startupsthisishowdesignworks.com/
Radical simplicity