SlideShare une entreprise Scribd logo
1  sur  57
Télécharger pour lire hors ligne
1
The Trouble With
All Those Boxes
Designing for ecosystems and
people instead of screens and
pages
@shoobe01 #mLearnCon
2
3
4
55
66
7
8
―I'm as interested in "channels"
as a thing when designing
ecosystems as I am in pages
when reading a book.‖
– Andrea Resmini
@resmini
99
10
11
12
13
―What we’re doing is trying to
translocate information, and all
the machine does is impair that
process. Possibly infinitely. You
have a choice over where it
goes, and that’s it.‖
– Martin Geddes
@hypervoice
1414
1515
16
1717
1818
19
• Design for Every Screen
• Mobile is More
• Design for Failure
20
• Design for Every Screen
• Mobile is More
• Design for Failure
21
Mobile First?
22
23
2424
25
26
27
28
29
30
Design for Every Screen
Blueprint
• Goals, objectives of the business
• Legacy systems, business constraints
• Put users on the paper
• Task flow/Storyboard/ID/IA/… Concept
• Platform agonstic < - > Every platform
31
• Design for Every Screen
• Mobile is More
• Design for Failure
3232
33
Wrong
3434
35
―…inequality is where the
opportunities/challenges for
design really are.‖
– Andrea Resmini
@resmini
36
Every platform is a unique and
special snowflake.
37
3838
3939
40
41
Mobile is More
Branch Design to Platforms
• Pick your platforms
• Mark/strike interactions for each platform
• Design by widget/module
• Embrace polymorphism
• Design for re-use
42
• Design for Every Screen
• Mobile is More
• Design for Failure
4343
44
45
―when these subsystems are
combined into larger
systems, we enter the world of
non-linear dynamics, complex
interactions, chaotic behavior —
and often, disastrous non-
resilience...‖
– Michael Mehaffy
tectics.com
46
47
4848
49
50
5151
52
Resilience Design Method:
1. Evaluate by widget
2. Determine user tolerance
3. Rate by severity
53
Design for Failure
Evaluate, avoid, fix
• Evaluate each component for pitfalls
• Detrmine user tolerance
• Rate severity, risk
• Can you avoid the issue?
• Can you mitigate the issue?
54
Philosophy, Not Process
55
Contact me for consulting, design, to
follow up on this deck, or just to talk:
Steven Hoober
steven@4ourth.com
+1 816 210 045
@shoobe01
shoobe01 on:
www.4ourth.com
56
57
Every platform is fragmented

Contenu connexe

Similaire à The Trouble with All Those Boxes: Designing for Ecosystems Instead of Screens

Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...
Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...
Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...Steven Hoober
 
How to design stuff that matters fast - Dev Week 2014
How to design stuff that matters fast - Dev Week 2014How to design stuff that matters fast - Dev Week 2014
How to design stuff that matters fast - Dev Week 2014Eewei Chen
 
Emerging technology presentation tablets
Emerging technology presentation   tabletsEmerging technology presentation   tablets
Emerging technology presentation tabletskmeeson
 
Is This a Button? A Question Your Users Should Never Ask.
Is This a Button? A Question Your Users Should Never Ask.Is This a Button? A Question Your Users Should Never Ask.
Is This a Button? A Question Your Users Should Never Ask.Andrew Malek
 
Designing for ecosystems and people instead of screens and pages
Designing for ecosystems and people instead of screens and pages Designing for ecosystems and people instead of screens and pages
Designing for ecosystems and people instead of screens and pages Steven Hoober
 
Digital Product Design's Biggest Challenge
Digital Product Design's Biggest ChallengeDigital Product Design's Biggest Challenge
Digital Product Design's Biggest ChallengeEva Willis
 
Responsive design lunch and learn
Responsive design lunch and learnResponsive design lunch and learn
Responsive design lunch and learnRicardo Queiroz
 
Great American Teach In - What is UX
Great American Teach In - What is UXGreat American Teach In - What is UX
Great American Teach In - What is UXMike Gallers
 
Accessibility & Universal Design
Accessibility & Universal DesignAccessibility & Universal Design
Accessibility & Universal DesignSrutiVijaykumar
 
Designing for Mobility
Designing for MobilityDesigning for Mobility
Designing for MobilityKelly Page
 
MTC13 Android UIs für alle(s)
MTC13 Android UIs für alle(s)MTC13 Android UIs für alle(s)
MTC13 Android UIs für alle(s)Andreas Hölzl
 
New Frontier of Multimodal Interfaces: Are you ready?
New Frontier of Multimodal Interfaces: Are you ready?New Frontier of Multimodal Interfaces: Are you ready?
New Frontier of Multimodal Interfaces: Are you ready?Marti Gold
 
Technology for Small Museums
Technology for Small MuseumsTechnology for Small Museums
Technology for Small MuseumsK L
 
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)Jennifer Romano Bergstrom
 
Web and-mobile-trends-2013
Web and-mobile-trends-2013Web and-mobile-trends-2013
Web and-mobile-trends-2013Anne Madsen
 
Inleiding tot chi
Inleiding tot chiInleiding tot chi
Inleiding tot chiErik Duval
 
Unleash Your Inner Unicorn
Unleash Your Inner UnicornUnleash Your Inner Unicorn
Unleash Your Inner UnicornMatt Baxter
 
Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Anders Ramsay
 

Similaire à The Trouble with All Those Boxes: Designing for Ecosystems Instead of Screens (20)

Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...
Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...
Turning Boxes into Ecosystems: Successful multi-channel, multi-platform, mult...
 
How to design stuff that matters fast - Dev Week 2014
How to design stuff that matters fast - Dev Week 2014How to design stuff that matters fast - Dev Week 2014
How to design stuff that matters fast - Dev Week 2014
 
Emerging technology presentation tablets
Emerging technology presentation   tabletsEmerging technology presentation   tablets
Emerging technology presentation tablets
 
Is This a Button? A Question Your Users Should Never Ask.
Is This a Button? A Question Your Users Should Never Ask.Is This a Button? A Question Your Users Should Never Ask.
Is This a Button? A Question Your Users Should Never Ask.
 
Uxperts mobi 2013 soa & challenges
Uxperts mobi 2013   soa & challengesUxperts mobi 2013   soa & challenges
Uxperts mobi 2013 soa & challenges
 
Designing for ecosystems and people instead of screens and pages
Designing for ecosystems and people instead of screens and pages Designing for ecosystems and people instead of screens and pages
Designing for ecosystems and people instead of screens and pages
 
Digital Product Design's Biggest Challenge
Digital Product Design's Biggest ChallengeDigital Product Design's Biggest Challenge
Digital Product Design's Biggest Challenge
 
Responsive design lunch and learn
Responsive design lunch and learnResponsive design lunch and learn
Responsive design lunch and learn
 
Great American Teach In - What is UX
Great American Teach In - What is UXGreat American Teach In - What is UX
Great American Teach In - What is UX
 
Accessibility & Universal Design
Accessibility & Universal DesignAccessibility & Universal Design
Accessibility & Universal Design
 
Designing for Mobility
Designing for MobilityDesigning for Mobility
Designing for Mobility
 
MTC13 Android UIs für alle(s)
MTC13 Android UIs für alle(s)MTC13 Android UIs für alle(s)
MTC13 Android UIs für alle(s)
 
New Frontier of Multimodal Interfaces: Are you ready?
New Frontier of Multimodal Interfaces: Are you ready?New Frontier of Multimodal Interfaces: Are you ready?
New Frontier of Multimodal Interfaces: Are you ready?
 
Technology for Small Museums
Technology for Small MuseumsTechnology for Small Museums
Technology for Small Museums
 
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)
Unifying the UX of a Survey Across Multiple Devices (MoDevEast 2013)
 
Web and-mobile-trends-2013
Web and-mobile-trends-2013Web and-mobile-trends-2013
Web and-mobile-trends-2013
 
Web and-mobile-trends-2013
Web and-mobile-trends-2013Web and-mobile-trends-2013
Web and-mobile-trends-2013
 
Inleiding tot chi
Inleiding tot chiInleiding tot chi
Inleiding tot chi
 
Unleash Your Inner Unicorn
Unleash Your Inner UnicornUnleash Your Inner Unicorn
Unleash Your Inner Unicorn
 
Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)
 

Plus de Steven Hoober

Mobile Usability and User Experience
Mobile Usability and User ExperienceMobile Usability and User Experience
Mobile Usability and User ExperienceSteven Hoober
 
1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile DesignSteven Hoober
 
1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile DesignSteven Hoober
 
UX for Mobile with Steven Hoober at Pointworks Academy
UX for Mobile with Steven Hoober at Pointworks AcademyUX for Mobile with Steven Hoober at Pointworks Academy
UX for Mobile with Steven Hoober at Pointworks AcademySteven Hoober
 
Designing Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsDesigning Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsSteven Hoober
 
Flatly Authentic Digital Design
Flatly Authentic Digital DesignFlatly Authentic Digital Design
Flatly Authentic Digital DesignSteven Hoober
 
Phones Aren’t Flat: Designing for People, Data & Ecosystems
Phones Aren’t Flat: Designing for People, Data & EcosystemsPhones Aren’t Flat: Designing for People, Data & Ecosystems
Phones Aren’t Flat: Designing for People, Data & EcosystemsSteven Hoober
 
Designing Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsDesigning Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsSteven Hoober
 
Fingers, Thumbs & People - 15 minute version
Fingers, Thumbs & People - 15 minute versionFingers, Thumbs & People - 15 minute version
Fingers, Thumbs & People - 15 minute versionSteven Hoober
 
Fingers, Thumbs & People: Designing for the way your users really hold and t...
Fingers, Thumbs & People: Designing for the way your users really hold and t...Fingers, Thumbs & People: Designing for the way your users really hold and t...
Fingers, Thumbs & People: Designing for the way your users really hold and t...Steven Hoober
 
API First: Creating ecosystems instead of products
API First: Creating ecosystems instead of productsAPI First: Creating ecosystems instead of products
API First: Creating ecosystems instead of productsSteven Hoober
 
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...Steven Hoober
 
How People Really Hold and Touch (their Phones)
How People Really Hold and Touch (their Phones)How People Really Hold and Touch (their Phones)
How People Really Hold and Touch (their Phones)Steven Hoober
 
Tools for Mobile UX Design
Tools for Mobile UX DesignTools for Mobile UX Design
Tools for Mobile UX DesignSteven Hoober
 
Getting Good UX Into Mobile
Getting Good UX Into MobileGetting Good UX Into Mobile
Getting Good UX Into MobileSteven Hoober
 
Entrepreneurial User Experience: Improving your products on a shoestring
Entrepreneurial User Experience: Improving your products on a shoestringEntrepreneurial User Experience: Improving your products on a shoestring
Entrepreneurial User Experience: Improving your products on a shoestringSteven Hoober
 
Design for Fingers, Thumbs & People
Design for Fingers, Thumbs & PeopleDesign for Fingers, Thumbs & People
Design for Fingers, Thumbs & PeopleSteven Hoober
 
Mobile Design: Adding Mobile to Your Learning Ecosystem
Mobile Design: Adding Mobile to Your Learning EcosystemMobile Design: Adding Mobile to Your Learning Ecosystem
Mobile Design: Adding Mobile to Your Learning EcosystemSteven Hoober
 
How People Really Hold & Touch (their phones)
How People Really Hold & Touch (their phones)How People Really Hold & Touch (their phones)
How People Really Hold & Touch (their phones)Steven Hoober
 
Introduction to Mobile for (Web) Designers
Introduction to Mobile for (Web) DesignersIntroduction to Mobile for (Web) Designers
Introduction to Mobile for (Web) DesignersSteven Hoober
 

Plus de Steven Hoober (20)

Mobile Usability and User Experience
Mobile Usability and User ExperienceMobile Usability and User Experience
Mobile Usability and User Experience
 
1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design
 
1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design1, 2, 3 for Better Mobile Design
1, 2, 3 for Better Mobile Design
 
UX for Mobile with Steven Hoober at Pointworks Academy
UX for Mobile with Steven Hoober at Pointworks AcademyUX for Mobile with Steven Hoober at Pointworks Academy
UX for Mobile with Steven Hoober at Pointworks Academy
 
Designing Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsDesigning Ecosystems, Not Just Apps
Designing Ecosystems, Not Just Apps
 
Flatly Authentic Digital Design
Flatly Authentic Digital DesignFlatly Authentic Digital Design
Flatly Authentic Digital Design
 
Phones Aren’t Flat: Designing for People, Data & Ecosystems
Phones Aren’t Flat: Designing for People, Data & EcosystemsPhones Aren’t Flat: Designing for People, Data & Ecosystems
Phones Aren’t Flat: Designing for People, Data & Ecosystems
 
Designing Ecosystems, Not Just Apps
Designing Ecosystems, Not Just AppsDesigning Ecosystems, Not Just Apps
Designing Ecosystems, Not Just Apps
 
Fingers, Thumbs & People - 15 minute version
Fingers, Thumbs & People - 15 minute versionFingers, Thumbs & People - 15 minute version
Fingers, Thumbs & People - 15 minute version
 
Fingers, Thumbs & People: Designing for the way your users really hold and t...
Fingers, Thumbs & People: Designing for the way your users really hold and t...Fingers, Thumbs & People: Designing for the way your users really hold and t...
Fingers, Thumbs & People: Designing for the way your users really hold and t...
 
API First: Creating ecosystems instead of products
API First: Creating ecosystems instead of productsAPI First: Creating ecosystems instead of products
API First: Creating ecosystems instead of products
 
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...
Physical, Digital, Human: Designing Experiences for Mobile and the Internet o...
 
How People Really Hold and Touch (their Phones)
How People Really Hold and Touch (their Phones)How People Really Hold and Touch (their Phones)
How People Really Hold and Touch (their Phones)
 
Tools for Mobile UX Design
Tools for Mobile UX DesignTools for Mobile UX Design
Tools for Mobile UX Design
 
Getting Good UX Into Mobile
Getting Good UX Into MobileGetting Good UX Into Mobile
Getting Good UX Into Mobile
 
Entrepreneurial User Experience: Improving your products on a shoestring
Entrepreneurial User Experience: Improving your products on a shoestringEntrepreneurial User Experience: Improving your products on a shoestring
Entrepreneurial User Experience: Improving your products on a shoestring
 
Design for Fingers, Thumbs & People
Design for Fingers, Thumbs & PeopleDesign for Fingers, Thumbs & People
Design for Fingers, Thumbs & People
 
Mobile Design: Adding Mobile to Your Learning Ecosystem
Mobile Design: Adding Mobile to Your Learning EcosystemMobile Design: Adding Mobile to Your Learning Ecosystem
Mobile Design: Adding Mobile to Your Learning Ecosystem
 
How People Really Hold & Touch (their phones)
How People Really Hold & Touch (their phones)How People Really Hold & Touch (their phones)
How People Really Hold & Touch (their phones)
 
Introduction to Mobile for (Web) Designers
Introduction to Mobile for (Web) DesignersIntroduction to Mobile for (Web) Designers
Introduction to Mobile for (Web) Designers
 

Dernier

IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 

Dernier (20)

IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 

The Trouble with All Those Boxes: Designing for Ecosystems Instead of Screens

Notes de l'éditeur

  1. …We all design-- and I mean technical design as well as UXdesign -- based on boxes. We love our boxes.
  2. Whether they are big, metal boxes moved by forklift or the little plastic boxes in our pockets, we tend to forget that they are connected, shared and used to do work in the real world.
  3. And because it’s all about the computer, we forget to “think like a human.” We design features, systems, tasks and content that fit into little boxes. Into computer screens, and flowcharts that show paths between little boxes of information. We design processes that progress in predictable, linear ways. In ways that work like businesses, and like computers. That think of the the system without considering the user, and present information in little boxes of content, on glowing screens. No, the guidelines I have heard even here today of making simple processes don’t work because users don’t have this diagram, and don’t think like that anyway.
  4. And by the way, we call these “systems,” but we don’t really mean it. Systems are inter-related, multi-part, and generalized. Systems are toolboxes with drawers full of capabilities. When most of us are building a website or application, we’re building tools. Tools do one thing, in more or less one way.
  5. There have been plenty of complex information and computational systems for a long time, but networks changed everything. If we think about networks, we consider them as connections between machines, delivering packets (more boxes on the diagrams) of data between them. Network connectivity is just another feature of the device.
  6. But that’s not quite right. Networks do not connect computers. Networks don’t even exist, really. And thinking of networks as packet delivery mechanisms doesn’t really help. Networks are instead just ways of making our computers bigger. Of making the world be one, large, distributed computing and storage system. You don’t use the cloud, you are part of it.
  7. When you think like this, you should start noticing the boundaries between channels or device classes start breaking down.
  8. Think about that.  How would you design your product if it wasn’t for an iPhone screen, but for the whole world? I am not kidding, or weaving crazy tales. How does, say, Facebook work? Or Twitter?
  9. They work on the Web, both mobile and desktop. On apps and widgets on handsets, and computers. On smart TVs, and Twitter especially is famously over SMS. In email. Don’t underestimate the power of email. Via push messaging platforms. Via APIs. As services. These, and others, are services that can be used by their owners, or in some cases by anyone, to offer the product in all sorts of ways. In ways that could not be predicted when they started. But they had one key winning attribute: that theydon’t need to predict in detail how it will be used, on what platform. They can just build servicesso we can build interfaces (or let others) to any platform, any time they want to. Yes, that’s a kiosk. And the featurephone? Last time someone could calculate the numbers (they are hidden now) 82 million regular users of the J2ME app on FEATUREPHONES. Less than half the Android or iOS platform, but that’s a lot of people; don’t you wish you had a spare 80 million users? It is a lot of opportunity when 80% of the world is still on featurephones.
  10. Lest you think everyone big and successful is doing it right and not missing a beat, let me use a counter-example. I don’t use Flicker much from mobile because it fails me. When I click a link in an email, or Google search, I most often get… the desktop website inside the browser. I am not even so worried about them not having a mobile site:They need a custom URI. They need to launch the app they are so proud of every time someone thinks “Flickr” on mobile. They are thinking of boxes, instead of systems and have checked the box for “mobile app” without thinking about the whole ecosystem or how we use this stuff. The other day, Dave Malouf sent me some tweets about how he couldn’t clearly follow someone’s Flipboard, as it… I can’t even remember. But does something that presents you a blank page if you don’t press the right button in some popup. We are smarter than this.
  11. Or back to Flickrhere, they are chasing the competition onboxes. Check the box that says “we offer filters!” Why? Does this meet some specific need of THEIR users? And why is it only on the mobile app? It’s not on the desktop, so is clearly not a service but a little widget residing locally in the apps. I think they even have different filters between the iOS and Android apps.
  12. Some people will go even further. Our happy glowing screens on all our beloved devices are actually getting in the way. I’ve been told by someone very clever about networks “what we’re doing is trying to translocate information, and all the machine does is impair that process. Possibly infinitely. You have a choice over where it goes, and that’s it.” Networks can be thought of only as delay-engines, and all our access platforms (our phones, computers and web browsers) as methods to divorce us further from the innate truth and meaning of the information.
  13. It doesn’t mean you don’t do the best possible job when designing interfaces. But first, you allow arbitrary access, so there’s customer choice; they get to pick the platform they are most comfortable with.And you need to push to platforms that fulfill these needs. Any platform. Screen-free platforms, like this are critical not just for special classes of uses, but to assist everyone in using technology all the time. We get “temporarily disabled” so need vibration and voice readouts. And users become exposed to your information from several sources, so it becomes almost ambient. Think about where and how your information can do the most good.
  14. We should never expose the edges of the system like this, much less require the user to tap the screen (button or not) to have the system try again. We need to design and build with an understanding… no, an expectation of delay, and difficulty. Both technical delays and because of our lives. Users get interrupted, and switch platforms. Networks fail, and stall, and delay. We have to cache data, allow working offline, build for multi-channel, multi-device use cases. We have to automatically synch and not cause errors when there are mismatches. We should build resilient systems that encourage sharing so users can resume tasks when they get home, or get to work and sit down.
  15. If you don’t get what I mean, or why, let’s take a specific case, maps. This is not about how Apple tried to get me lost driving in Europe. And I did the screencaps a couple months back so it may be a bit out of date. You might need maps when you are far into the boonies. Or you want to know where you are going next while in a tunnel, in one of the no-network area on an underground subway. A month or two ago, I used an iPhone on my bike mount driving around San Francisco, but didn’t bother to put in a SIM. I have lots of phones, most don’t have plans so I carried another one with me as well. I just cached the maps and used GPS alone. Implementations vary, in ways that are useful to illustrate this: Google maps on iOS does… nothing. If you are off network, you get a useless blur. Google maps on Android does a better job of having a “basemap,” a permanently cached global map, but you can maybe find half a dozen towns per state, and maybe none per country in sub-saharan Africa. They do have a service to manually cache areas, but you have to plan ahead. And can only save so many of these. iOS Maps has, despite other flaws, probably the best overall solution: It automatically caches. If you have looked at the area lately, it’ll keep it stored offline. So if you plan your trip, then go there soon enough it’s saved.
  16. If you do any of this adaptive stuff wrong, or don’t do it at all, users will notice. I like to use map caching as an easy-to-see example, but generally, users are intolerant of bad systems. There is an increasing body of actual research that everyday users do not use, for example, tablet apps that are obviously just phone apps stretched to fit the screen (photo). Or, take Facebook’s hybrid app failure. This was not a nerdy developer and designer issue, but everyday people rejected a major service and stopped using the app. We know this because they admitted to a sustained 4-fold increase in use almost overnight, when they launched the first native app. Do not dismiss these concerns as nerdy, niggling disagreements. We’re all nerds now, and your users care.
  17. Let me show you another example. Pebble, the eWatch, changed my life. Not really. But it’s really a shockingly interesting product and I’ll tell you about it if you care sometime,except there are oddities and pitfalls. The first use experience is a perfect example. There are no instructions on the box per se, it has just a website address, and the device says almost nothing when you turn it on. The link could have been emailed to me. Better would be that they help me get the app installed a few days before the watch arrives, also with email links or something similar. The watch has not enough info, and the app doesn’t make much of anything clear. You have to read the web page, which might as well be a printed VCR manual. It’s long, it’s tedious, it’s jargon-tastic.
  18. Okay…I think most of you are nodding, or have similar thoughts from the exercise, because we already know how to do all this the right way. And I suspect everything else I’ll tell you in the next few slides you know also. Connecting the two is what is key. Some of these concepts might be new, but most of all I am talking about creating cultures that encourage building great products. There are a lot of principles and practices and concepts and examples and pithy phrases I could give you. I do change my mind and modify this periodically, but today I think if we could all get to a common understanding of these three points, we could do a lot better for our products, our clients and our users.
  19. Design for Every Screen is my attempt at a clever catchphrase. Of course, I don’t just mean screens, but “platforms” somehowsounds less great and they are sorta not real either so that would be worth arguing also. It’s essentially whatJakob Nielsen calls the “Transmedia User Experience,“ which is even less catchy, so I don’t feel so bad. You can also think of it as designing agnostic of any interface (maybe even with NO interface), or designing for services.
  20. This is also my counter to things like how “Mobile First,” which isn’t bad, butis too often misinterpreted to mean a different excusive choice.While it&apos;s better than “desktop Web first,” Mobile Firstis a fundamentally Web-centric thought process, and is too focused on screen size; it&apos;s the kind of thing that meshes with RWD, whereas there&apos;s a lot more to design and development. If you like Responsive, skip it and think Adaptive instead.
  21. Pragmatically, tactically, there are too many mobiles also. Are you supposed to start with the lowest capability mobile device, like here where I&apos;ve got a search dialogue. It works well enough for that, but…
  22. …the capabilities of more advanced mobile platforms allow much more interesting interactions, which have nothing to do with size, and not much to do with input method.If I designed the one first and progressively enhanced, I am not sure I&apos;d have come up with these.
  23. In the end, I meandesigning for people. About half my work is for Big Dumb Companies, for legacy systems and services and to integrate with or build on existing products. It means when you do the discovery work you already do, like seeing how people shop for greeting cards (photo) you don’t just take it as input but turn that directly into task flows and architectures. You don’t make assumptions about presentation layer, platform or technology, but you let the user needs (and business needs, and so on) but let those evolve organically from the design process.
  24. When you write, or draw concepts, they should talk about services, data, sensors, networks and users. Not screens. Don’t just put your goals and objectives on the wall, or on the first page of the deck, but bake them into the diagram. This is what I think of as a Task Map, and my Customer Journey Maps look similar. With no start, no stop and no happy path. Lots of circles.
  25. Storyboard. Think about processes from entirely the user’s point of view. Storyboards are a great way to force yourself to think about users, their context, and their behaviors off the screen.
  26. Of course, you can also do screens the same way. Draw comps parallel to the storyboard, or like this with bits of the user and context. And, you don’t need to settle on a platform for this. Here, it’s SMS, notifications and apps. Sketched out as part of the user task.
  27. Detailed IA diagrams, task flows, system models like this are just a natural extension of these concepts. Draw these as evolutions from the concept, storyboard and other phases. Designagnostically, as we already do with IA principles and deliverables, then branch (by module, not page!!!) to the platforms you identify is the way to make sure you design the best experience for each of those platforms. I call these Blueprints to differentiate from the similar task flow IA diagrams that you make as you branch this to each platform.
  28. Never let project constraints keep you from conceiving of future interfaces, to make sure the architecture, the whole solution, is future friendly. When thinking of systems, or creating blueprint level diagrams and concepts, “never say never.” Okay, this particular smart TV widget didn’t launch yet. But it’s on the roadmap, and everyone from the CEO to the data architects knows it is.
  29. Summary of
  30. Mobile is More. Not less.
  31. The standard line, which I am /still hearing people say/ is that mobile is smaller and less capable, so you must “ruthlessly cut” features, content, etc. This means, in comparison to desktop. A tablet is in between, so you cut half the features, I guess.
  32. WrongThat assumes desktops are the ultimate. Everything else is less. Mobile is smaller.
  33. But there’s more to it. Every device is different, and every device is good in its own way. For scale, size hardly even matters in many cases. Angular resolution and viewing distance cause a lot of this to disappear.
  34. Not disappear in the sense of merge, but because the capabilities and interactions are matched to the way they are used. Embrace these differences.
  35. These differences in device capabilities are great. This is stuff that gets me excited! Mobiles are in no way like desktop computers. And they are not like cars. And your smart thermostat, or watch are not like each other or anything else.
  36. In a lot more ways more than the size of the screen. Or the input method. Most of all due to connectivity and sensors. Many devices are taking the mobile cue of being very aware of their environment, and their user. And also, critically, more seamless access to the features most computers have like connectivity. Data entry, for example, can be made trivial:by removing it. Since the device is reliably connected, and full of sensors, it canalready knowwhat the user wants.
  37. I know this isn’t a mobile phone, but it’s a great example that’s easy to see and understand, and is a good way to talk about how no-interface and pre-emptive tasking is probably the future anyway. It’s a hand-washing station. You press a button for water, then a button for soap, then a button for water, then a button for air, then dry your hands on your shirt. They each come out different places, so you move your hands to different positions. Which is not enough to turn it you. You really do have to press a button. Wet, soapy, etc. In this day and age. Unsanitary? Mostly, un-necessary. Sensors are (seriously) cheaper than buttons and can make the experience a LOT better.
  38. We have to design, each platform, every platform, to take advantage of the features inherent to it, and the unique environment, and user expectations.There are sexier items like location, but sharing is my favorite example of mobile vs. web. Not the concept, but the implementation where you just press “Share” is brilliantly good stuff. It appeals to the way people cognitively address tasks like this. If you are building email forms into your desktop website, that’s correct. That’s the standard. But for mobile web and apps, that’s wrong. You link to installed applications because that’s the expectation and method of operation of mobiles.
  39. Do whatever is right for whatever system you and your users work with.TV, and kiosks and telematics and so on will all have their good points. And these are ALL here. Millions of Smart TV downloads have already been sold. You’ve all seen you can now develop for cars. Mobile handsets and tablets are, relatively, easy to understand. You have to stop thinking of mobiles as tiny, crippled desktops, with weird touch interfaces that mean you can’t use hover states. You need to embrace the network connectivity, the portability, the presence, the sensors, the intelligence, the integration, the personalization.
  40. Time to really draw. Take the concepts and states in your task flow, and draw the interfaces.Draw everything at device scale. I have a few sheets of phone outlines to help with this, but you can just draw boxes on your page that are close to scale instead. Do not forget interactions; show paths and motion and delay. Design by widgets. Think not about screens, but components. How can this component be used other places. This can be a good team exercise, as one draws a widget someone else is marking on the task flow diagram all the views or states it will apply to. Use colored markers and letters or something to annotate the relationship.
  41. …Who here has heard of Resilience Engineering, as an engineering and security practice? It is used to keep services like Google, Facebook, Etsy, Flickr, Yahoo, or Amazon online. At a deep engineering level they follow practices and procedures to assure their systems are not brittle, and avoid failure or fail gracefully and can be fixed easily. Well, we rarely need to design end-user systems for true catastrophes, but for any digital product there are many failure modes we simply are not accounting for. And we really should.
  42. Resilience is usually defined as the ability of a system to absorb disruptions without tipping over to a new kind of order. A building when exposed to too much lateral ground movement settles into a state of “pile of rubble on the ground” unless you design it to resist this disruption adequately. We approach all design of technical systems from the engineering perspective, and assume we can codify the process, so predict failure points. We can’t. Our systems are embedded in other technical systems, embedded into complex systems, like the user carrying it around, who may be subject to rain, and traffic delays, and screaming babies.
  43. I say there’s something called Resilience Design. Or there should be. Here’s a simple example… I also still wear normal watches. One is a dive watch, because it’s shiny, not because I am a diver or anything. It is one of those with a twisty ring around the outside. That part with the numbers twists around. If you don&apos;t know, and I didn&apos;t until recently, this is used as a simple timer. But on mine, and on all dive watches (vs. Aviators watches), the ring only goes one way. The clicky detent lets it go counter-clockwise, only. Why? … Because it&apos;s for timing remaining air. The ring might get bumped and change it&apos;s setting. Having it show less time might be inconvenient, but going the other way might kill you. And, you don&apos;t even need to know this. It just works. That&apos;s the sort of brilliantly-simple answer I am talking about with resilient design.
  44. This [watch] might seem like it is dirt simple and free-standing, but it works like that because of it is part of a system. You wear it. You do things that require timing. Resilient structures are designed as parts of interconnected networks, not as free standing items, and not hierarchies or linear processes. We need to design our systems to work with users’ messy lives. To account for arbitrary complexity, chaos, and failure.
  45. Failure means anything you didn’t predict. It means planning on users missing the target on their small touchscreen. So it’s not catastrophic, and maybe so the whole system works better anyway. It means you never say the word “happy path” again, much less design for it. Users do not enter your site (or app) from the “home page” anymore. Stop designing like that. (This is a site I run. These are real numbers.) I don’t pay much attention to the way the home page works anymore.
  46. More specifically, and maybe easier to get your hands on, is that people cannot click perfectly. There’s a talk tomorrow morning about these figures, but if you put two click targets too close, people will hit the wrong one way too much. This Twitter client is typical. If you try to click these links, you can miss and hit the user line instead.
  47. This other Twitter client – just to prove that it has nothing to do with the type of product – solves it easily. These look like links, but clicking anywhere on the line opens up this drawer with options.Sure, it’s a second click, but it’s better than accidents, and once the user is accustomed to it then it works real fast.
  48. Say you are building a store locator function as part of your tablet app. You don’t ask users to type their location in, do you? Because the device knows already. I don’t even put in “Search” buttons for things like this (not that I claim to have built this Square wallet app I am showing off here), and at least for maps, most designers don’t. When you open the feature, you get a map. With results already fetched in the background so there’s no delay.
  49. Even when you allow typing, you do it intelligently. You think about what users know, care about and tolerate. This IS something I am working on (it’s not launched just yet so don’t complain about the details; there are probably open bugs on them). It automatically detects location and populates it. Note here it’s only got coarse location so we don’t use the centroid of the area and call it a street address. We use the data we have correctly, within the constraints we know. But it also lets the user type. Not lat/long figures, not precise addresses. Who knows the postal code when visiting a store? Nope, we use the Google Places API which lets you type in place names. Stores, landmarks, stuff that people think of the way they think about it. Yes, it offers autocomplete options, so the user can type just a few characters sometimes, and tap to pick from the list. And this didn’t even muddle our data structure as any result the user accepts turns into a geocoded address in the location field and a store name in a field elsewhere.
  50. I have mentioned modularity a few times, and wanted to briefly touch on how important that is. Remember all those complex, interconnected systems? It is mathematically impractical to address every use case. When considering the available combinations of choices a user could make on many systems, combinatorial variations are in the billions. I did some rough math on one project and determined the documentation and analysis would take longer than the history of the universe to that time to complete. This one [image] isn’t that bad, but is a real example of a not-very-complex website a few years back. We can discuss development and QA efficiencies of modularity, but in design it gives you additional advantages of evaluation. If there are six states of a search module, that’s easy to consider, and adding one is no big deal. Designing and specifying those states per page is orders of magnitude harder. Evaluating them with all plausible information types can be impossible.
  51. Methods: Principles are great, but how do we do this? 1) Evaluate by widgets. systems /thinking/ is great, but evaluating at a systems level is literally impossible. So, for each widget or module,figure out what all modes it operates in, including error states and other sub-optimal conditions. 2) Tolerance. How much will the user, based on their abilities, their context, and their desire to complete the task tolerate failure? Thinking of this, you&apos;ll see that failure can be not system errors; required registration before using a website is part of this because the user doesn&apos;t want to do it, the registration system gets in their way, and since they don&apos;t want to do it, they have low tolerance. Then you end up with reduced registration… You could even use HF methods to calculate the difficulty of selection and input, and the cognitive load, and if you work in a life/health/safety field I&apos;d do that, but I never bother. Low, medium, high with a brief explanation is good. 3) Severity. How bad is the error or unexpected condition? You can even assign numbers to it, which can be pretty accurate if you do it as a team exercise, with everyone doing an expert review /by persona/, you can also cross it with the tolerance level per widget and get a hint as to what the specific pitfalls might be, so you can fix the most troublesome conditions.
  52. Take your existing designs, the task flow and the interfaces, and use these techniques to review for failure. The evaluation process cannot be so formal in the short time we have available, so just take whatever comes to mind quickly, then modify the design to fix it. Do you need to change the whole flow, or would changing a button label or position be enough?
  53. In case you haven’t picked up on that, or I accidentally implied these are steps in a process, they aren’t. You should use all these during your design process, but routinely. If not hourly, then check for resilience and consider platform specifics daily. Eventually, you can do this automatically. It becomes second nature. To me, I am serious when I say this is developing a philosophy of design.
  54. So, whose confused, disagrees or doesn’t see how it applies to them?
  55. APPENDIX: Slides that didn’t make it due to time and flow. But I might use as examples during Q&amp;A. If this multi-platform stuff worries you, or if you are someone who gripes about fragmentation, you are doing it wrong. First, we’re UX designers. The users are making choices of these platforms, and all these device sizes. They are not being tricked into it, they are not cheapskates no matter what Gizmodo says. You must to respect user choice of device and platform. Use analytics and not opinion to make your decisions. Implementation-wise, another platform is a simple, easy extension to your core /service/. I’ll say it again: most of us should not be designing and building apps or sites, but services that happen to have a variety of front ends. How easy is it to extend? I know people who have launched on another platform by adding one person to the team. One Android developer, some designers you already had on staff, and literally weeks later there’s a beta version to play with. I know people who have had alpha ports to a new platform within ONE DAY.
  56. APPENDIX: Slides that didn’t make it due to time and flow. But I might use as examples during Q&amp;A. If you think your favorite platform is not subject to fragmentation, you are just ignoring the people who can’t use your product. iOS has different, but broad issues of device and OS compatibility. Sometimes, depending on the product you are making, worse ones than Android.