How and why should software designers make ‘continuous design and improvements’ a priority in the development process? This is the question guest blogger Rob James explores in the following guest post. Rob James is a skilled programmer who loves the design process of software development. He can be found blogging about software development, or writing reviews of software (many of which are currently available on the market).

***

When working on software, it’s important to remember the principle of continuous design, and how it can ultimately benefit a final product. Continued design reflects an approach where different versions of software can be developed through iterative and incremental design for retesting and improvement, rather than being extensively planned out and produced in a linear way. Whether working on commodity trading software or database design, the value of creating, testing, and improving cannot be understated.

More traditional software design processes involve a waterfall model, whereby careful planning takes place at the start of a project’s lifecycle, and is then developed through to a final stage for testing. By comparison, continued design can affect iterative and incremental strategies, as well as evolutionary design and agile models. In this context, less planning is made at the start of a project, and more versions of software developed and testing in a cyclical way.

In this process, developers work on continued testing and changes to a project – the aim here is to learn from testing and feedback of real models, rather than working on a software project through to completion and then having to deal with problems. Redesigning and elaborating on small parts of a software application can depend on extensive alterations in the evolution of a product.

By being more flexible with rapidly developing and troubleshooting prototypes, software companies can fix issues with software during an ongoing lifecycle. This cyclical approach can be useful in terms of widening the number of options for software development as different prototypes are tested, from architecture through to applications, as well as in regards to the end user experience.

In terms of design, incremental approaches to evolving software focuses on continual improvement and the fine tuning of features by going back over the same problems and finding solutions. Each new version is able to benefit from the mistakes of the last, creating  what developer Jeremy Miller describes as a ‘process of continuous design that happens throughout the project life cycle.’ Martin Fowler and Pramod Sandalage also advocate an approach to software design where bugs and the general architecture of a project are worked out over time and improved by consistent testing and feedback from users.

Fowler and Sandalage argue that ‘you assume that you cannot fix the requirements of the system up-front’ in the planning stage, but instead have to go through many different versions of a software platform before it gets to where it needs to be. This kind of agile planning can work to embrace change, rather than trying to get everything set up at the beginning of the design process. Fowler and Sandalage go on to suggest that ‘you look at design as an on-going process that is interleaved with construction, testing, and even delivery,’ with software expected to adapt and go through multiple versions before and after it reaches users. By doing so, it’s possible for software designers to make continuous design and improvements an important factor in producing the best possible software.

Last month, uTest introduced a brand new UI for Apphance, a mobile quality tool that makes it easy for mobile app developers to understand how their apps are working across a wide range of mobile devices, carriers and locations. After making so many improvements to the UI, we’re ready to turn our attention to the other half of the Apphance software stack – the SDKs. Today we’re launching a new and improved version of the iOS SDK, version 1.8.8, that adds several features and enhancements our users have been asking for. Let’s take a look at a few of the big ones:

Two-Finger Swipe Bug Reporting

One of Apphance’s coolest features is in-app bug reporting. You simply shake the device and Apphance responds by taking a screenshot and allowing the user to write a complete bug report right on the device itself. Our customers love this feature because it allows them to see bugs in the same context as they were discovered, along with important details and information about the device and app state.

While most users prefer to trigger bug reports by shaking the device, some of our customers have asked us for an alternative. Many of them use the accelerometer for other purposes, or they’re developing fitness apps where the device is always in motion. With this new update, we’re introducing an alternative (and optional) bug reporting approach that relies on swiping your fingers upwards from the lower corners of the screen.

Instructions for changing the bug reporting mechanism are available in the Apphance help topics. By default, Apphance will still trigger bug reports using the accelerometer, but switching to the two-finger swipe method can be accomplished by adding just two lines of code.

Read more …

Have you ever heard someone say, “I think I’ll just develop this app real quick”?

Didn’t think so. Developing an app isn’t something you can just crank out. Theoretically you could – but it certainly wouldn’t be a chart-topping application. Developing a successful app takes careful planning and analysis. David Tucker, in Mashable, recently pulled together a list of things to consider when developing an app. Here’s a look at the highlights:

• Agree on goals for the program.
• Understand your target users.
• Identify a minimally viable solution set.
• Plan for multiple releases.
• Balance your users and your business.
• Know what is out there.
• Bring your IT team into the discussions early.
• Decide on a technology you can live (and grow) with.
• Plan to analyze.

Many of these considerations closely tie into app testing, especially planning for multiple releases. Tucker says:

“Statistics show that many users will re-engage with your application when new features are added. Spread key functionality across the first handful of releases to keep your users engaged.”

In a perfect world releases would only contain new functionality, but the majority of the time releases are put in place with fixes to bugs and other issues. The hard part is getting to the root of any present issues before you’ve lost any users. Through real world testing developers can discover any bugs, patch any them, and release a new version of their app so any current users don’t drop off or uninstall the app out of frustration.

Another extremely important consideration is ‘planning to analyze’. According to Tucker:

“The final step in the process is determining how to measure success. With a morass of potential features, devices, platforms and technologies, success can be challenging to define, but it will affect your ultimate strategy. Consider the following questions.

• Will this increase our transaction volume and, therefore, revenue?
• Will this increase customer adoption and retention?
• Will this increase our brand recognition and loyalty?
• Will this decrease our costs?
• How many people do we want using our app?
• How do we want to integrate the solution with our social media program?
• How will we integrate with our existing analytics tools”

However, defining and tracking success after you launch your app is just as, if not more important. Tracking what users think of your app’s privacy, content, elegance, etc. can not only give you an idea of what users think about your app – but it can help you frame your app updates and new releases. Through regular analysis you can maintain and boost user engagement, furthering your app’s success. Overall -when it comes to mobile apps – the planning never truly ends.

How do you plan for mobile app development? Share your best practices in the comments section.

All Things D caught up with Mozilla CEO Gary Kovacs recently to discuss the company’s foray into mobile operating systems. The video discusses the new Firefox OS’s roll-out plan (hint: it isn’t coming to the US right off the bat), how the system combines apps and web features and how Firefox OS makes finding information (apps or websites) easier.

If you build it they will come…unless it’s mobile web only. We can now add LinkedIn to the long list of companies that find HTML5 promising, but who cannot forgo native apps in its favor. Why is this the case? Simple: Users still spend more time in native apps.

VentureBeat sat down with Kiran Prasad, LinkedIn’s Sr. Director of Mobile Engineering, who explained the company’s decision to once again focus on native apps over HTML5:

We have definitely shifted from HTML5 to native. The primary reason for that is, we’re seeing that more and more people are spending  more time in the app, and the app is running out of memory. It’s not performance issues, like speed or rendering, but it’s still a big problem.

The second reason we’ve gone native is trying to get some of the animations —  the spinners and the way they work — getting that smoothness, we felt like we needed native to really do that well.

The way we built our system, we used template JSONs. We always have to support  HTML5 because so much of our traffic comes from email. When we were [serving] a  smaller group [of users], we were hoping we could duplicate all that mobile web work to make our clients faster in terms of code deploys. It worked really well when mobile only made up 8 to 10 percent of traffic. … I’m not sure I could have predicted it, but we recognize now that HTML5 is not allowing us to do the best  for our users.

Read the Rest >>>

The App Quality Alliance (AQuA) – a global group made up of manufacturers, carriers and other parties involved with mobile apps – put together a handy list of the “Top 10 App Errors Good QA Helps You to Avoid.” Here are my five favorite:

1. User interface inconsistency – The UI must be consistent throughout the app, including the consistency of soft key references.

4. Language inconsistency and spelling errors – Text displayed in a localised version of the app needs to be consistent throughout, and must be free of spelling errors in all languages.

5. Privacy policy omission – A privacy policy must always be clear within the app.

9. Network connectivity: Lack of notification – When the app uses network capabilities it must be able to handle situations where network connectivity is not possible, delayed or lost through the display of relevant and timely information to the user.

10. Screen orientation distortion - The display must not be distorted when changing between landscape and portrait display mode.

See the full list from AQuA >>>

It’s true, all 10 errors highlighted on AQuA’s list can be avoided with some good QA work, but it’s important to remember that no one type of testing will catch all these issues.

Many of the issues – like interface and ease of navigation problems – would show up during usability testing. Others are squarely functional issues (I’m looking at you #7). And a few of the issues on the list will likely only be flushed out with dedicated security testing or localization testing.

Read over AQuA’s list and making sure none of these glaring errors are slipping through the cracks of your testing.

Google Glass is shipping and first generation users can expect to have the newest mobilewear tech in their hands soon. But what good is a new device if it doesn’t have many apps? As it turns out, you won’t have to wait long  for Google Glass apps – er, “Glassware.”

While things will likely start slowly at first (TechCrunch is reporting that only developers with a physical Glass device will be able to access the Glass API for the time being), Google has added a Glass section to its developers site. The site gives potential developers, testers and other interested parties a look at how Glassware (aka, apps) will work and what Google expects from third party developers.

In addition to the API, quick start guides for Java and Python and walk-throughs of several key Glass features, the site also outlines best practices for Glass in general, its user interface and best performance tips. The best practices all boil down to four main points Google is doing its best to promote:

• Design for Glass – Design, build, and test your application specifically for Glass to ensure that the user experience is appropriate.
• Don’t get in the way – Glass users expect the technology to be there when they want it and out of the way when they don’t. Don’t be too frequent and loud with notifications when the user doesn’t expect it.
• Keep it timely – Glass is a platform that is most effective when in-the-moment and up-to-date.
• Avoid the unexpected – Surprising the user with unexpected functionality is bad on any platform, but especially on Glass given how close it is to their daily experience. Be honest about the intention of your application, what you will do on the user’s behalf, and get their explicit permission before you do it.

Google understands the importance of in-the-wild testing – and it practices what it preaches!

You’ve heard the web vs. native app debate time and time again. As a developer you’ve weighed the pros and cons to determine which development approach to take, and as a consumer you’ve mulled over the two options for your own mobile usage.

But Gartner indicates this debate could soon dissolve with increased adoption of the hybrid development approach. According to Nathan Eddy, of eWeek, Gartner predicts the hybrid approach will be used in more than 50% of mobile apps by 2016:

“According to the report, so far the promise of HTML5—a widely used language for structuring and presenting content on the Internet–and its offline capabilities and animation-rich tools have fallen short of expectations, which in turn has caused developers to consider hybrid architectures to better leverage mobile device capabilities.

‘The BYOD trend and the increased pressure on organizations to deploy mobile applications to accommodate mobile work styles of employees will lead businesses to manage a portfolio of mobile application architectures, and hybrid architectures will be especially well-suited to business-to-employee applications,’ Van Baker, research vice president at Gartner, said in a statement. ‘The implications for IT is that the era of PC dominance with Windows as the single platform will be replaced with a post-PC era where Windows is one of a variety of environments that IT will need to support.’”

If Gartner’s predictions are correct the adoption of hybrid apps will grow fast, with 2016 merely three years away. Then the real question becomes, if hybrid apps offer so many benefits why haven’t they already been heavily adopted? Matt Baxter-Reynolds, of ZDNet, believes that while the concept of hybrid apps is great, we simply have not been able to get hybrid apps work:

“Building a hybrid app means you build your software using HTML5/JavaScript and package it up in an app that can be installed on a device. Because it’s running locally and in a native device package, hybrid apps can do things like access the GPS, camera, etc.

Managing to get an app working on multiple platforms is a huge pain. Somehow we’ve engineered (no pun intended) our way into a situation where we can’t easily take code from, say, iOS to Android and then to Windows Phone. Any hop between platforms needs reengineering. If you build a hybrid app, you should, in theory, just be able to get away with writing it once and repackaging the same code for other platforms. That’s a huge win.

I think the reason why initiatives to build hybrid apps that fail become newsworthy is that people really want this idea to work. It seems logical. It seems proper. Failure piques the interest of those developers following the story.

The only problem with hybrid apps is that it’s nigh-on impossible to make them work. And that’s quite a big problem.”

Testing across platforms will be a major challenge for hybrid app developers, and already is one for native and web app developers. This is why testing under real world conditions across carriers, devices, operating systems, platforms – you name it – is such an important part of a development team’s QA process. With the right testing, developers can get their apps to work, the first time and every time.

We want to hear from you… what do you think of hybrid apps and of Gartner’s prediction? Share your thought in the comments section.

When you think about bad mobile app security, Android tends to come to mind. The open nature of Android makes it (theoretically) easier for malicious apps to find their way into the app store and onto users’ devices. While intentionally malicious apps may be a problem for Android, when it comes to data leaks and the loss of personal information iOS is actually a bigger security offender, according to Veracode’s recent State of Software Security report. From Computer Weekly:

Surprisingly, 26% of Android apps exhibited information leakage bugs, compared with 42% on iOS. This covers the leakage of personal information such as email, text messages, GPS coordinates, and the content of users’ address books.

“When you install Android, it requests access to certain phone functionality. The app developer has to request explicit access, while on iOS a developer does not have to request access,” said [Chris Eng, vice-president of research at Veracode].

Even when developers take the extra steps to make their apps secure, their approaches may be miss guided. Trying to build in cryptographic keys to protect user data can actually make security worse if not done correctly. This issue is troubling for both major operating systems.

Overall, cryptographic issues affected a sizeable portion of Android (64%) and iOS (58%) applications.

The report warned that using cryptographic mechanisms incorrectly can make it easier for attackers to compromise the application. Cryptographic keys are used to protect transmitted or stored data.

It found that in some applications, developers had hard-coded a cryptographic key directly into a mobile application. Should these hard-coded keys be compromised, any security mechanisms that depend on the privacy of the keys are rendered ineffective.

Mobile app security is complicated. Developers and testers need to keep working to understand the issues and learn how to best address them.