About porting mobile applications to Windows Phone and Windows 8 platforms
Many companies are thinking about developing mobile clients for their services for Windows Phone and Windows 8. In most cases, mobile clients for iOS / Android have already been written and the company's task is to port them to Windows mobile platforms. About what questions / problems / features companies and developers might face, I would like to talk in this article.
Do as well!
The most frequent formulation of the problem, with which we had to face, sounds like this: here is a client for Android / iOS, do the same.
This is the most common mistake that in the long run can cost developers a big headache, and the customer an unforeseen cost.
')
Generally speaking, the development of a (good) mobile application should consist of several important steps:
Oddly enough, the development is important, but not key. I can also say with confidence that the appearance is also not always an important component. More important is usability, compliance with guidelines and convenience of executing the main scenarios (the average application should have no more than five).
General advice: design an application for a specific platform. It is very important to understand that saving resources for designing “native” interfaces can turn out negatively for their creators or customers. Standard solutions for one platform are absolutely not standard for another.
Let's look at a few examples. For example, the application Correspondent for Windows Phone:
Let's compare these screenshots with screenshots for iOS and Android:
I think that if you remove the top panel from the screenshots, then an inexperienced user is unlikely to be able to distinguish for which platform the application was developed.
The desire of companies to increase brand awareness is understandable. But not at the cost of usability applications for the end user. Therefore, it is better to provide the user with a native application for a specific platform.
Compare with LinkedIn:
And branding is present and immediately understandable for which platform the application is made.
The need to use standard controls, even despite the fact that there is a great temptation to do "not like everyone else", can be attributed to this point.
For example, the UC Browser application contains quite an interesting solution for navigation, but it does not fit into the general approach at all. When you click on the open menu button, this panel appears with tabs inside the application bar:
I still have not decided whether this was justified or not (from the point of view of the developer and user), but the fact that I had to think about it suggests that the design might have to be done differently.
Windows Phone and Windows 8 are authentic digital floating platforms, unlike, for example, iOS. What this means is easy to explain with the example of the Klnizhny shelf for iOS, where a person’s behavior when reading a magazine or book is “imitated” from real life - we go to the bookshelf, pull out a magazine, open it and leaf through it. For Windows Phone, this process looks completely divorced from “real” life and is initially focused on the digital world, where there is no such thing as a “bookshelf”.
The second difference from iOS / Andoid is the emphasis on content and focus on action. On Windows Phone and Windows 8, phone numbers and email addresses will be written in small fonts, and “call” or “send email” actions will be large. Large fonts and indents are another Metro feature. This also needs to be considered when designing interfaces.
There are several aspects to consider before planning applications on Windows Phone and Windows 8.
1. Android, to a greater extent, is tied to the Google ecosystem, iOS - to the Apple ecosystem, Windows Phone and Windows 8, therefore, to the Microsoft ecosystem. This can be both an advantage and a disadvantage. For example, it will be easier for you to work with office documents, but instead of tight integration with the dropbox, you will be offered to use skydrive.
2. Platform restrictions. Windows Phone is a rather strict platform. There are clear restrictions on the launch time of the application, the size of downloaded files depending on the type of Internet connection, the number of background operations, etc. Due to such limitations, even the “native” for Windows Phone Skype does not always work as expected from a full-fledged messenger.
3. Specific requirements for scenarios in Windows 8. In Windows 8 there are so-called contracts - Search, Share and others, with the help of which such scripts as “search by application”, “share something with social networks or open a file in another are executed appendix ". Separately, it is necessary to say about Settings and Share - in Windows 8 they should be in the sidebar and only in it. Duplication of functionality within the application is not very desirable.
4. Navigation model in Windows Phone and Windows 8 are different. If Windows Phone navigation is mostly linear (non-linear navigation is allowed only in exceptional cases and is thoroughly tested), then Windows 8 is more loyal to the navigation model. Moreover, you need to think about the possibility of quick access to the main screens of the application from any screen.
5. Windows Phone 7.5 vs. Windows Phone 8. You need to remember that now there are several major versions of Windows Phone:
If you decide to support the 7.x platform, then you need to consider whether you will support Tango devices (low cost) that are more sensitive to the memory consumed by applications. If you need NFC or in-app purchases (IAP), then you need to focus on Windows Phone 8.0 or support two versions of the application (7.x and 8.x).
Despite the fact that Windows Phone supports NDK, applications cannot be created entirely in C ++. You can create components, work with Direct-X and connect external libraries, but non-gaming applications still need to be written in C # / VB.NET (XAML is possible only with the help of these languages).
Applications for Windows 8 can be written including in C ++. For Windows 8 is also an important issue of compilation for different architectures - x32, x64, ARM. This question is quite voluminous, perhaps we will write an article about it separately.
It is impossible to create a 100% cross-platform application for Windows Phone and Windows 8, despite the fact that they have a common core. Navigation, UI components, camera work, speech sdk, navigation model are those things that are different. Third-party libraries must also be compiled for a specific platform, which is why for Windows 8 not all familiar libraries will be available.
And, again, the difference between Windows Phone and Windows 8 - in Windows 8, working with local storage is slightly different + there is no SQL CE (database engine), because of which the data layer also needs to be rewritten, and it is best to abstract from specific implementations data storage engine.
Thanks for attention!
PS If you have interesting suggestions on the following topics of publications - please let me know in any convenient way.
Do as well!
The most frequent formulation of the problem, with which we had to face, sounds like this: here is a client for Android / iOS, do the same.
This is the most common mistake that in the long run can cost developers a big headache, and the customer an unforeseen cost.
')
Generally speaking, the development of a (good) mobile application should consist of several important steps:
- formulation of the problem;
- prototype creation. This can be either a paper version in the form of an interaction scheme or a stub application with test data — it doesn't matter. In the process of creating a prototype, the process of finding the optimal variant of the implementation of the main scenarios of work, finding structural and logical problems, discussing the usability of the application;
- work on graphics and application design;
- application development;
- work on optimizing the speed of the application;
- testing;
- preparing for the publication of the application in the store;
- publication of the application;
- collecting analytics and getting feedback;
- fix bugs and release updates.
Oddly enough, the development is important, but not key. I can also say with confidence that the appearance is also not always an important component. More important is usability, compliance with guidelines and convenience of executing the main scenarios (the average application should have no more than five).
General advice: design an application for a specific platform. It is very important to understand that saving resources for designing “native” interfaces can turn out negatively for their creators or customers. Standard solutions for one platform are absolutely not standard for another.
Let's look at a few examples. For example, the application Correspondent for Windows Phone:
Let's compare these screenshots with screenshots for iOS and Android:
I think that if you remove the top panel from the screenshots, then an inexperienced user is unlikely to be able to distinguish for which platform the application was developed.
The desire of companies to increase brand awareness is understandable. But not at the cost of usability applications for the end user. Therefore, it is better to provide the user with a native application for a specific platform.
Compare with LinkedIn:
And branding is present and immediately understandable for which platform the application is made.
The need to use standard controls, even despite the fact that there is a great temptation to do "not like everyone else", can be attributed to this point.
For example, the UC Browser application contains quite an interesting solution for navigation, but it does not fit into the general approach at all. When you click on the open menu button, this panel appears with tabs inside the application bar:
I still have not decided whether this was justified or not (from the point of view of the developer and user), but the fact that I had to think about it suggests that the design might have to be done differently.
What is important to know about the interface Modern UI aka Metro
Windows Phone and Windows 8 are authentic digital floating platforms, unlike, for example, iOS. What this means is easy to explain with the example of the Klnizhny shelf for iOS, where a person’s behavior when reading a magazine or book is “imitated” from real life - we go to the bookshelf, pull out a magazine, open it and leaf through it. For Windows Phone, this process looks completely divorced from “real” life and is initially focused on the digital world, where there is no such thing as a “bookshelf”.
The second difference from iOS / Andoid is the emphasis on content and focus on action. On Windows Phone and Windows 8, phone numbers and email addresses will be written in small fonts, and “call” or “send email” actions will be large. Large fonts and indents are another Metro feature. This also needs to be considered when designing interfaces.
Other platform features
There are several aspects to consider before planning applications on Windows Phone and Windows 8.
1. Android, to a greater extent, is tied to the Google ecosystem, iOS - to the Apple ecosystem, Windows Phone and Windows 8, therefore, to the Microsoft ecosystem. This can be both an advantage and a disadvantage. For example, it will be easier for you to work with office documents, but instead of tight integration with the dropbox, you will be offered to use skydrive.
2. Platform restrictions. Windows Phone is a rather strict platform. There are clear restrictions on the launch time of the application, the size of downloaded files depending on the type of Internet connection, the number of background operations, etc. Due to such limitations, even the “native” for Windows Phone Skype does not always work as expected from a full-fledged messenger.
3. Specific requirements for scenarios in Windows 8. In Windows 8 there are so-called contracts - Search, Share and others, with the help of which such scripts as “search by application”, “share something with social networks or open a file in another are executed appendix ". Separately, it is necessary to say about Settings and Share - in Windows 8 they should be in the sidebar and only in it. Duplication of functionality within the application is not very desirable.
4. Navigation model in Windows Phone and Windows 8 are different. If Windows Phone navigation is mostly linear (non-linear navigation is allowed only in exceptional cases and is thoroughly tested), then Windows 8 is more loyal to the navigation model. Moreover, you need to think about the possibility of quick access to the main screens of the application from any screen.
5. Windows Phone 7.5 vs. Windows Phone 8. You need to remember that now there are several major versions of Windows Phone:
- Mango - Windows Phone 7.5 (512 MB of memory);
- Mango - Windows Phone 7.8 (512 MB of memory) - has not yet been updated;
- Tango - Windows Phone 7.5 (256 MB of memory);
- Apollo - Windows Phone 8.
If you decide to support the 7.x platform, then you need to consider whether you will support Tango devices (low cost) that are more sensitive to the memory consumed by applications. If you need NFC or in-app purchases (IAP), then you need to focus on Windows Phone 8.0 or support two versions of the application (7.x and 8.x).
Cross-platform between Windows Phone 8 and Windows 8
Despite the fact that Windows Phone supports NDK, applications cannot be created entirely in C ++. You can create components, work with Direct-X and connect external libraries, but non-gaming applications still need to be written in C # / VB.NET (XAML is possible only with the help of these languages).
Applications for Windows 8 can be written including in C ++. For Windows 8 is also an important issue of compilation for different architectures - x32, x64, ARM. This question is quite voluminous, perhaps we will write an article about it separately.
It is impossible to create a 100% cross-platform application for Windows Phone and Windows 8, despite the fact that they have a common core. Navigation, UI components, camera work, speech sdk, navigation model are those things that are different. Third-party libraries must also be compiled for a specific platform, which is why for Windows 8 not all familiar libraries will be available.
And, again, the difference between Windows Phone and Windows 8 - in Windows 8, working with local storage is slightly different + there is no SQL CE (database engine), because of which the data layer also needs to be rewritten, and it is best to abstract from specific implementations data storage engine.
Thanks for attention!
PS If you have interesting suggestions on the following topics of publications - please let me know in any convenient way.
Source: https://habr.com/ru/post/160175/
All Articles