Tag Archives: mobile

On Voice Apps (2013)

Posted on by

Future of Mobile
Image Source: The Future of the Web and Mobile (Feb 2007)

For years I have been working on mobile and related software development. This has been a world of “data”-and consumer and enterprise applications and infrastructure, that for me started in 1999-2000 with CDPD, CDMA, then GSM, 2G, 3G, and today 4G and LTE from the network side, and from the device side Symbian OS, WinCE, Palm OS, RIM, WML, HTML Basic, J2ME, and into today’s iOS and Android (Smartphone and Tablets) as the main platforms for native apps and HTML5 webapps.

More recently, I have been deeply involved with Voice as an App.

Evolution of Mobile

Mobile has truly gone through a period of tremendous evolution and growth. Mobile is about convenience and easy access (to others and to information). The mobile Smartphone is a social artifact. And while today I believe that mobile has peaked in general (a topic for another blog), mobile has entered the phase of continuous stable growth that won’t stop — its essence will just transform into different form-factors and new interactions — all about improving the mobile context and thus the experience (usefulness).

Voice has always been a fundamental piece or feature of the mobile phone, and it will always be. But in the world or era of “data”, voice has been treated as “legacy stuff”, separate and driven by its own experience, drivers, and infrastructure. Voice just works, but separate, under Operator control.

As a side note, for years, many of us have been talking about convergence with respect to mobile; an example of this is a piece I wrote back in 2007 titled the Future of the Web and Mobile that covered the expected evolution of mobile from my point of view — this was written 6 months before the iPhone was first released; looking back is pretty much on target.

The early part of the 2000 decade saw technologies, concepts and lessons-learned from Europe (Nokia), Canada (RIM), Asia and USA (Palm, MSFT, others), but their impact remained pretty much closed as well as localized to the respective regions (mainly due to Operator control). Then the years 2005-2008 were the fundamental years of transformation, and openness away from Operator control and into the Ecosystem, first in the USA (thanks to Apple and Google) which then impacted the rest of the world in big ways, into what Mobile is today. Throughout that same time-period we have been talking about the convergence with voice, but this in my opinion has never really happened. I am talking about bringing voice convergence to the next level — from the device into the App-level.

On Voice Apps

Voice is by default a multi-platform application. But the future points to voice as a dominant “mobile app”. The consumer world is massively becoming mobile, and the enterprise world will be eliminating the traditional office phones in favor of mobile. Interestingly, the effects of BYOD also impact Voice apps as well.

Even though the technologies for creating voice apps have been around for a while, today we are still kind stuck in a different world when it comes to voice: a 100+ year old world of closed voice-networks, arbitrage, peering, FCC and PSTNs regulations and other. There is a lot of history on how we got there, but for folks that come from the world of “data”, like I do, it all looks like quite a mess. Thankfully, it is an “old world” that is slowly evolving (while in the process, crashing) with the new world. I am right in the middle of this world today. One day, all of this will be completely freed from such legacy world, thanks to open IP networks, mobile, the Web, the Cloud and new business models.

Voice is slowly but surely moving into becoming a “data app” — Voice as an app or an app feature. Voice will continue to be the Smartphones *main* feature (or app). Primarily standalone. But primarily standalone with many flavors or choices beyond the “core voice support” provided by the Network Operator (for example, Google Voice). These are SIP and WebRTC clients that you can download and use, point-to-point or via the old PSTN.

Google Voice
Google Voice. Image Source: The Next Web website

Cloud-services companies such as Plivo and Twilio are helping with this evolution to provide Voice as an app or app-feature.

Because of the current state of “voice” as an app, depending on the “app layer” you are at, the moment you want to open your voice app to complete calls to any phone out there (that is, the PSTN), you will immediately “crash” into the legacy world of voice. This is a hardcore world of telephone numbers, activations and inventories, origination and termination and routing, agreements, and fees and regulations. To effectively deal with all of this you either have to implement all of this directly (costly), or you can use solutions on the cloud, such as the services-and Marketplace provided by Shango (my company) and its partners.

From the design perspective, designing mobile apps with voice functionality does require a different way of thinking from designing traditional mobile apps and web apps. The inclusion of voice as an interaction mode does require re-thinking of your application as a multi-modal app. And because voice apps is about communication, the whole thing can quickly turn into including or not other kinds of communication such as IM, SMS, video, and group-communications (conferencing), and other.

Conclusion

The mobile device, the Smartphone, is a social artifact — it has always been. Voice has always been the fundamental feature on these highly personal devices. But we have always been treating voice “as its own separate function”. Voice is changing. Voice as an app or app-feature is coming, and is coming fast. BYOD has an impact on Voice apps that must be taken into consideration.

We are at a very interesting crosspoint where the old legacy voice world is moving into the new world of “data” and Cloud-based services and apps. The Cloud service providers to help create, manage and support such voice apps are out there, the Smartphones provide the support for native SIP stacks and libraries to write and/or include voice functionality into your app, WebRTC is coming, and you can download your own SIP clients/apps to use as well.

The future is clear: open IP networks, Mobile and Cloud-service providers are and will play an important role in the evolution of voice communications, voice as an app and the future of “Mobile”.

ceo

Dell is going Private (2013)

Posted on by

potential_dell_dial_2013

A month after I wrote Dell to exit global smartphone business, now I hear rumors that Dell is going private.

Many years ago I was predicting that an Asian company would buy Dell, but I wasn’t expecting Dell going private.

The Dell story kind of upset me. Dell, which is right on my “backyard”, is/was an Austin darling, used to rule the personal computing world. Today, I am not surprised of what is happening at Dell; I have been saying this for years. The Round Rock, Texas company missed the boat in a major way. You need to understand that this didn’t happen over night. It has been a slow but expected process/result — I am talking about 10 years, which is the same time-period that it took personal computing/Mobile to evolve into what it is right at this moment — just look around and you know what I am talking about: Smartphones, Tablets, personal information devices. This mess all started during the days of Kevin Rollings.

For Dell, Mobile always meant laptops. The company wasn’t able to understand that personal computing was transforming, right in front of their eyes, into the new form of Tablets and Smartphones. Actually, some inside the company did, and they created prototypes and Tablets and Smartphones *but* without a proper business-plan and without proper vision. They thought they were in control, but they weren’t. Then, they couldn’t adapt fast-enough. They couldn’t make it happen; didn’t know how-to. Technology leadership requires vision and investing in R&D — Dell didn’t do either. Then Apple and Google-and its partners all ate Dell’s lunch. It wasn’t a tech problem, but a total lack of vision — a business (management) problem. Shame on you Dell management.

Rumors say that Microsoft would invest $2 billion on the deal. Good money — but Dell would once again miss to identify root causes. Dell needs to understand that part of the reason it has failed and is failing is truly related to its dependency on Microsoft for all things Software. Dell needs to realize and learn that Software is where differentiation comes from. Software runs the world. It must take ownership and leadership both on software and hardware.

It is no surprise why both Dell and Microsoft missed the personal computing boat — the mobile opportunity. It is a problem with the way of thinking and lack of vision (that is, lack of proper leadership).

As I wrote recently, moving forward, Services and Cloud is perhaps what Dell should focus on, and forget about the rest. The problem is that Dell’s dependency on PC revenue is still at 70%; it is a tough problem to solve.

The new personal computing (aka Mobile) is perhaps too late for Dell at this point. But with the right leadership, anything can happen. If Dell insists on addressing the personal computing market, it must do a re-boot, and bring totally new minds (business and tech) into the equation — something they should be able to do now if they go Private.

ceo

Startup Showcase at Texas Wireless Summit 2012

Posted on by

This Friday October 26, 2012 is the Texas Wireless Summit. And as part of the event we are having the annual Mobile Monday Austin Startup Showcase.

(Also, don’t forget that on Oct 22 we are having our regular Mobile Monday Austin event at Capital Factory — topic: Mobile & Cloud.)

This year we are having a strong presence of Startups — 13 total showcasing their mobile apps and solutions; awesome:

1* Baytan Labs — http://baytanlabs.com
2* CanWeNetwork — http://www.canwenetwork.com
3* Divert-X – http://divert-x.com
4* DrawMD / Visual Health — http://escalation-point.com
5* EMMOCO — http://emmoco.com
6* News Blast – http://sxtyscnds.com
7* Noom — http://www.noom.me
8* Ringful — http://ringful.com
9* Toopher — http://toopher.com
10* Vivogig — http://vivogig.com
11* VolunteerSpot — http://volunteerspot.com
12* Wheel InnovationZ — http://wheelinnovationz.com
13* Zello — http://zello.com

Looking back at previous App Showcases at TWS, it is great to see companies that at the time were just starting, and that today are doing quite well, for example 1) MapMyFitness, 2) Game Salad, 3) Tabbedout.

As part of the showcase, judges that include the founder of Tabbedout, the CFO of Phunware, and yours truly, will judge the companies based on
(1) Originality, (2) Impact, (3) Maturity and (4) Business Plan/Model. The judges for this year are:

* Maria Ocampo — Head of Publisher Services at Collider Media
* Rick Orr — Founder Tabbedout
* Alan Kane — CFO Phunware
* Brian Grigsby — General Partner, Corsa Ventures
* D Keith Casey Jr — Evangelist at Twilio
* C. Enrique Ortiz — Head of Products at Shango

For more information about the Texas Wireless Summit and registration, visit TWS web site http://TWSUMMIT.COM.

CEO

Total Time Spend Using Mobile Web vs. Apps (October 2012)

Posted on by

Saw this today at BI website…

Source: Business Intelligence (BI)

Source: Apps More And More Important Than The Mobile Web (Business Intelligence). Original report by Nielsen.

The above is self-explanatory…

What I find ‘funny’ is that over time I have noticed that Business Intelligence’s opinion on “native vs. web on mobile” swings back-and-forth (based on the top news of the day). In this particular case, all the recent attention to “native vs. mobile web” is thanks to Mr. Zuckerberg.

ceo

The Eternal Debate — MoMo London Event on HTML5 v.s. Native (Sept 2012)

Posted on by

Native vs. Web
Image Source: Mobile App Testing Blog

Seems that I missed a very good debate. I just read a blog on MoMo London event on HTML5 v.s. Native.

Seems like an eternal debate.

Today in 2012, I am still amazed we still are debating this and have not been able to address this. This is really a ~10 year old debate, still driven by the exact same issues and pros/cons as before — centralized vs. not, cross-platform vs. not, maintainability and fragmentation, code-reusability or not, better user experience vs. not, performance, security, access to device APIs vs. not, thin vs. thick, app discovery, etc. etc. etc.

We can argue the basics are here (HTML5, CSS3 and JS-and-related frameworks), but creating great mobile webapps with great user experiences is today only possible by a few; in other words, is a niche area. (Not even Facebook was able to pull it off, right?).

The day the “common mobile developer” is able to create great mobile webapps with ease, is the day this debate will end.

Today still, “user experience” (driven by network latency, app richness, toolsets, adoption by big brands) is best maximized on mobile native. Today still we have to talk about classes of mobile applications (again driven by network, richness, performance, storage, toolsets, maintainability, security, cost of one vs. other, etc) — then decide what is better suited — native vs. web on mobile.

How much longer will it take settle out this debate? 3 years? 5 years? 10 years? Right now I say around five years — I wish I am wrong. But does it really matter?

In the meantime, successful mobile developers redefine the meaning of “full stack developers”; successful mobile developers must be “End-to-end, Cross-platform, Full Stack Developers” — this is a lot of complex ground to cover.

Related to this see “The biggest mistake we made as a company was not investing enough on native.” — Zuckerberg (2012).

ceo

Android Platform Versions (2012)

Posted on by

Below is a snapshot of the Android platform distribution, as of September 2012.

Android Platforms Sept 2012

As you can see, the majority of the devices out there, close to 60%, are still 2.3 (Gingerbread). This is followed by ICS with close to 21%. Froyo 2.2 is 14%.

I hope that by March (but more likely, summertime or later) of 2013, that by then the majority of the Android devices out there are 4.0+. This would make the Android app developer’s life in general much simpler — by (1) minimizing the number of major Android platforms to deal with, and (2) making it easier/cheaper to implement (or move up to) the recommended Android design guidelines. The result of this includes (1) cheaper to develop/maintain apps, (2) consistent apps per developer, and (3) consistent look/feel/behavior across the app market.

For this to happen, device manufacturers and operators must help transform the above piechart to be mostly 4.0+ Android devices. They can help by literally selling less (and even better, stop selling) Gingerbread/2.3 and older devices. If you look around you will see that operators are still selling Gingerbread devices. And we need Google to have more cojones with respect to this and stimulate, if you will, both the device manufacturers and operators to move forward — this transition is taking forever! (Note: Gingerbread was introduced on December 6, 2010.)

Some customers may leave feedback as “why the app does not follow the Android UI guidelines”, or “why the app doesn’t support the ICS UI paradigm” — but again, 4.0+ is just a smaller fraction of what is out there!

In the meantime, there is the Android Support (Compatibility) library. Also, see Backwards Compatibility (Android Design Patterns).

ceo

“The biggest mistake we made as a company was not investing enough on native.” — Zuckerberg (2012)

Posted on by

The title of this blog is not what Zuckerberg actually said, but is what he really meant.

From TechCrunch Disrupt – Zuckerberg Shows He’s The Right Man For The Job:

“The biggest mistake we made as a company was betting too much on HTML5.” While building native apps that were bacially just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. “We burnt two years.”

This validates what I have been saying for years… Don’t take me wrong, I’m a fan, user and developer of webapps. Web on mobile is big and the mobile browsers and frameworks are getting so advanced, and the mobile webapps so kickass, but for certain kinds of apps, especially rich consumer-based applications, native is the way to go today.

Consumers are about great user experiences and great quality. The “mistake” Zuckerberg refers to is not really that they bet “too much” on HTML5, but that they didn’t invest enough on native.

But that said, FB has nailed it down; recognizing the need to invest on the native apps and related infrastructure, and focusing on mobile first.

Any company going global must have a mobile first strategy — we know that for many around the world, their online experience will be on mobile.

ceo

Starbucks App == Mobile + Convenience

Posted on by

The Starbucks App for Android 2.0 is out on Google Play (see announcement on VentureBeat).

Good to see…

(I was one of the people who contributed design & dev to this product, specifically the Card Management tab/functionality, plus some other.)

Starbucks have proven, starting with their iOS app, that consumers are ready for mobile payments — as of April 2012, Starbucks apps have done over 42M mobile payment transactions (see announcement on VentureBeat).

Awesome…

Convenience is always a big winner. In the case of Starbucks it is about payments, rewards and store information right on the palm of your hands.

There is another important aspect here. It also shows that stores must have the whole infrastructure in place to be successful:

  1. The POS that are enabled with the appropriate readers and software,
  2. The devices/smartphones with the SW and functions (the apps), and,
  3. The scalable service infrastructure with the appropriate back-end integrations, and the right kind of services-and content — in the case of Starbucks, authentication, payments, rewards, store information and related-integrations.

It is then that users will adopt this in masses; and, yes, it is about convenience.


(Card management tab with Pay Now, and embedded PayPal Integration for Card Reload)

Digital cards are at the center of the app. The app, which is global-ready, allows smartphone-users to load the digital cards (dollars, pounds, etc, depending on country) via credit cards and/or PayPal — all within the app, thus maximizing the user experience. The digital cards are then scanned at the stores. For this, the app uses 2D-barcodes that are scanned/read by the POS using regular barcode scanners, consummating the transaction.

Looking forward, this app is a good candidate for NFC and/or other proximity-based technologies. If the NFC infrastructure was in place, that is, the readers and the NFC-capable smartphones, I will bet that it would also be a winner. But full, pervasive NFC deployments are still are a few years away, delaying its adoption. As a result, today, 2D-barcodes is the way to go.


(This is not real, just a concept scenario that I put together for the Starbucks app with NFC support)

As mobile app designers, the important thing is to design your application in a way that 2D-barcodes or NFC or other are just interaction channels — the key is keeping the rest of the app- and related supporting infrastructure (servers, authentication, exposed services, payment infrastructure and so on) properly abstracted. As a side note, this is a reason why Square is ready for the future — it has all the infrastructure in place, and today their reader is the Square-reader, and tomorrow it can be something else. Starbucks is ready too.

ceo

Security & Privacy on Mobile Apps, Part 3 – PCI Compliance

Posted on by

This is Part 3 of a series on Security & Privacy for Mobile Apps.

Part 1 of this series introduced main concepts related to security on mobile apps. Part 2 went deeper into the security elements and guidelines related to security and privacy on mobile applications. In this Part 3, I will cover security from the PCI compliance perspective.

Handling Personal or Sensitive Information

Personal and sensitive information include any information that is critical for a user, for example credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Any such information must be properly handled and secured.

When dealing with credit cards in particular, you may have to adhere to strict security requirements such as the ones as defined by the Payment Card Industry Security Standards Council, or PCI for short. The PCI council defined a number of requirements and certification to help to ensure both devices and software applications all take the proper steps to protect cardholder data. The PCI council consists of the following companies: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.

Even if your application is not handling cardholder information, the requirements by the PCI council are good guidelines to follow if your mobile (web) application deals with personal sensitive information of any kind.

PCI Data Security Standard (DSS) requirements

Let’s take a look at the PCI Data Security Standard (DSS) requirements. These requirements apply to “any entity that stores, processes, and/or transmits cardholder data.” In short, “if your business accepts or processes payment cards, it must comply with the PCI DSS.” Note that “to comply”, means that the payment application must pass a PCI-provided assessment.

Table 1: Payment Application DSS Requirement

   Source: Payment Card Industry Security Standards

The PCI Data Security Standard defines fourteen (14) requirements — some technical while other operational — that affect both the server-side and client/mobile-side of the payment application. Let’s cover each of these requirements in some more detail:

1. Do not retain full magnetic stripe, card validation code or value or PIN block data

How to: Always prompt for such information; never store locally on the device. Always prompt for PIN.

2. Provide secure password features

How to: Always prompt for PIN before allowing access to the app’s critical paths or sensitive information. Use the PIN to secure application data.

3. Protect stored cardholder data

How to: Do not store cardholder information on the device. Tokenize access to critical information (tokens are covered below). Use the PIN to secure application data.

4. Log application activity

How to: Keep a local log of critical activities, such as when user logs into the application, performs a purchase, and so on. This typically is a circular log. Provide the means to remotely access or upload the log as needed.

5. Develop secure applications

How to: Design and implement the mobile application with security in mind. Do this by implementing the different requirements being discussed in this article.

6. Protect wireless transmissions

How to: Perform all communication over an encrypted secure connection (typically over HTTPS/TLS).

7. Test applications to address vulnerabilities

How to: Implement a robust test-suite that includes automated and manual testing that validates that no access to critical application paths is possible unless the user authorizes it via a PIN, that API calls and data over network connections is in fact being encrypted, that no credit card information is stored locally, and that any personal information stored in local data is properly encrypted.

8. Facilitate secure network implementation

How to: See #6 above

9. Do not store cardholder data on a server connected to the Internet

How to: Design a network architecture that separates production systems from the public Internet. Deploy production servers with critical/personal information behind a firewall.

10. Facilitate secure remote software updates

How to: Only trust software updates from trusted sources. Leverage app stores/markets and app signing for native applications. Leverage centralized approach of mobile web apps. Perform all software updates over a secure network connection.

11. Facilitate secure remote access to application

How to: See #10. In addition, see #6 — all remote/network communication shall only be done over secure network connections.

12. Encrypt sensitive traffic over public networks

How to: See #6 above

13. Encrypt all non-console administrative access

How to: See #4 and #6 and #10. All access to secure data, administrative or not, shall be done over secure connections.

14. Maintain instructional docs and training programs for customers, resellers and integrators

How to: From the mobile application perspective, provide FAQ and Help pages that describe the privacy and security aspects of the application. Include Privacy terms and conditions.

Other PCI Information and/or Requirements

The following two tables show the general PCI goals vs. requirements, and PIN-entry device security requirements.

Table 2: PCI Data Security Standard (DSS) requirements

   Source: Payment Card Industry Security Standards

Note that most of these requirements on Table 2 were covered on the previous section.

Table 3: PCI PIN Entry Device Security Requirements

   Source: Payment Card Industry Security Standards

And these requirements on Table 3 are related to physical devices, in particular device characteristics and management requirements.

Conclusion

On this 3-part series we have covered security on mobile applications – introduction, elements and guidelines for secure mobile apps, and PCI requirements for mobile payment applications. At the end, it is about protecting the user by protecting related critical information –credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII); all such information must be properly handled and secured.

As privacy continues to become more critical over time, with the number of apps exponentially increasing, and with potential legislation in the future, having clear privacy and security implementation, wording/messaging and responsibilities are all very important.

Finally, as product owners and developers, we are all responsible for properly implementing our mobile applications and protecting the user…

Resources

On Mobile Industry Numbers and Mobile Jobs

Posted on by

The other day I tweeted this:

(URL: https://twitter.com/eortiz/status/223096404233564160)

Then I read at the Royal Pingdom blog some interesting Internet 2011 in numbers; looking at the mobile-related numbers, we have:

Mobile (July 2012)

  • 1.2 billion – The number of active mobile broadband subscriptions worldwide in 2011.
  • 5.9 billion – The estimated number of mobile subscriptions worldwide in 2011.
  • 85% – Percentage of handsets shipped globally in 2011 that included a web browser.
  • 88% – Apple iPad’s share of global tablet web traffic in December.

    So the mobile space is a pretty hot space indeed. Let’s now look at some mobile-related job salary numbers, courtesy of Indeed Salary; note these are *average* salaries:

    Mobile Architect

    Mobile Developers

    Mobile Designer

    Mobile Web Developer

    Android Developer

    iOS Developer

    Windows Mobile Developer

    BlackBerry Developer

    Symbian OS Developer

    Mobile Product Manager

    I actually find this quite low for Mobile Product Managers.

    Mobile Project Manager

    Let’s now look at some trends, courtesy of Indeed Trends. Interesting is how it starts to trend up towards the end of 2010 for all the top mobile OS platforms –iOS, Android, HTML5:

    iOS Job Trends

    HTML5 Job Trends

    Android Job Trends

    Mobile-app Job Trends

    Symbian OS Job Trends

    Note the roller-coaster trend for Symbian OS…

    Windows Mobile Job Trends

    Interesting!

    BlackBerry Job Trends

    Conclusion

    So in conclusion, the mobile space is red HOT… The demand is there. It definitely is a good time to be a mobile technologist, developer, product manager, and so on… globally!

    CEO