Multi languages design can be tricky at times. This is because of the way how natural languages are structured. In some cases, you may have to design to group the languages or separate the design. This are some considerations and impact you may face while developing for multi language support.
Careful of your Layout
A common but annoying issue from multi languages support is the length of text. This can totally screw up your layout design. There will come a stage you may have to css for a specific language due to the long text. Another common occurrence is the font size and type. The type of languages used will impact the selection of font size and types. As a rule of thumb, go for simple layout and standard font type and size.
Defaultor User Specific Language Locale
Another consideration is to determine if you are going to allow default or user specific languages setting. Majority of application captured user language preference to individual users. However, this may be applicable to secured applications. For public settings, you may consider to use browser language locale or allow a one time setup. These preferences are usually the options you can configure or develop. So, you should select the options that suits best.
Multi languages development will incur additional efforts and considerations to layout and user preferences. It is best to setup multi languages from start. This way, you could determine if your support for multi languages are sufficient.
Multi languages development can be a quite challenging for a lot of system products. So far, I have not seen any applications with full languages support. If you are designing for Asia, this can be quite a catch for the diversity. For product evaluation, users should not be charged if they request for local languages support. Instead, it is how your product can easily configure for different languages. This is how my dream multi languages configuration will look like.
Set and Get Language Locale
Language locale is a required parameter in today global application. The system product must have options to get and set language locale. There is also instance where your application have been configured for a preset language locale. The locale property must be enabled for all product objects used in the UI. It is common to see LOV (List Of Values) dropdown neglected for this parameter.
Languages Resource Bundle and Translation Service
Two other important factors in your software evaluation is the capability to configure resource bundle and translation service. We should not be held ransom to product vendor to pay for translated local languages. Thus, the software product must allow you to add and maintain any resource bundles for multi languages support. You should also be allowed to add translation API to support if the text is not found for the particular locale.
The applications of today must provide multi languages development or configuration. You must evaluate software product for multi languages capabilities. These common factors includes ability to set and get user locale, maintenance of your own language resource bundle and addition of translation api. Thus, do look out for these features if you are looking for a software to cover offices globally.
System demo is getting easier now. However, a demo is not to be mistaken for POC (Proof of Concept). Non IT users often cannot differentiate between demo and POC. Here are some quick tips to know the differences.
Demo vs POC
The distinct differences between demo and POC are related to time, scope and cost. Demo are faster to show because you will be using existing test or demo data. Demo scope is limited to standard features that have already been implemented. Best of all, demo usually is free of charge. In contrast, POC may not be free because you would be setting up customer data for POC. In some cases, you may configure specific features pertaining for customer requests. Thus, POC will take a longer duration to be planned and setup like a project.
Set Your Expectations
When you are going to showcase your system, it is important to set the customer expectations. Non IT users also have the misconception of using excel for simulation and anticipate the system to behave in similar manner. The expectations will determine if your customers are looking for a demo or POC. You will need to plan your schedule carefully based on these expectations.
It is not surprising to see sales or non IT users mixing up the customer expectations for demo or POC. You may find yourself in a crunch to provide freebies POC as a disguised demo. Therefore, it is timely to educate your users on the key points for demo and POC
Many users or sales have the misconception of pleasing customer with promise of customisation to your system. However, this is not true as some services are better to be standardised and cost efficient. There is also a limit to please your customer without hurting your bottomline. What are the guidelines to avoid customising your system?
A Product View
Moving your business towards a product view is the first step to understand your customer base. A key reason of customisation is the fit of your product to customer needs. A poorly fit product will result up in a lot of customisation. You must adapt your product to fit the your targetted customer base. A well designed product should have a deviation of 10% customisation and 10% localisation.
Know your Customers
When you have decide to establish your application as a product, it it time to categorise your customer base. Your understanding of customers are important to refine your product into various types. High-end and well-paying customers can be provided with all the bells and whistles in applications. In contrast, you may not want an economic customers to be using your full featured product.
The basic guideline to stop the customisation trend for your application is to start thinking like a product. With a product view, you can position your application to each customer base. This will reduce your cost and increase your customer satisfaction with a better fit of product at valued pricing.
Should we have reopen as our status value? If you are familiar of status lifecycle values, you will realise that this is a very ambiguous status value. If you have the option to reopen, there will be no end to status. This is because your statistics will mess up due to this reopen.
If you are in engineering, you will learn about state diagram. It is a very good concept to manage your status value and its logical flow. Users love to provide various value for your status. Very soon, you may find overlapping status or conflicting status for your application. Give this method a try if you are facing a status meltdown.
Setting good status value is key to analysing your transactions. These are some good tips to setting good status and its values.
Keep your status type to less than 3 if you want to remember the status dependency.
Set your status value in a forward logical flow.
Avoid ambiguous status like reopen that will mess up your statistics.
Do not create conflicted status value for status type like Done for a status and “Pending” for the other.
Always have a start and end state to your status.
Status are key method in all data gathering and analysis. Users may not be the best person to determine the status. You may want to review and use state diagram to illustrate your status flow. Keep in mind the status tips to extract the best results in your data.
Today, I encounter another interesting requirements which state “depends on customer”. Being in project implementation for so long, I am still amused by this response. Why are there such requirements? Do not be surprised as such response is actually very common in Asian countries.
关系 as requirements
Asia cultures plays a big part in influencing the customer requirements. The “关系” aka as customer relationship is an unseen and very strong force. This practice is much prevalent in China, Japan and South Korea. It is no surprise that requirements can change upon customer requests. Naturally, it create challenges for the organisation as system is driven consumer customisation.
Customer is King
“Customer is King” is very common in Asia. With lower switching cost and labour cost, customers tend to be more fickle minded in Asia than American or EU countries. With the differences of leverages, organisations tends to accommodate customers for quick wins. Digital transformation also make it easier for customers to migrate their data across different platforms.
In Asia, requirements are driven largely by cultures. Power is a common play by customers to get what they wanted and as requested. You will usually need local help to elicit and mitigate such requirements. Only then, you can satisfy your customers and gain their trust.
Designing IT solution in Supply Chain is a constant dilemma. This is because we are trying to map the physical world into a digital plane. There will always be a constant timing and data gap in the system. So, how does we overcome this dilemma?
User expectations determines how you can tweak your supply chain system. The bullwhip effect actually applies for the information system as well. It is no uncommon for supply chain system to front facing to end users and vice versa. The dilemma happens when there is a mismatch of the system design with user expectations.
Real Time is Costly
Information flow is actually directly proportional to cost. The technology have provided cheaper real time information to users now. However, the change have not been effected to all existing systems built during the days of 2000s. It may take another five years or so before real time is the become a de facto standard. Meanwhile, it is a fact that all supply chain systems are only Near real time.
Many solutions that promised real time information update is nearly a hoax and dilemma in the year 2020s. This is because the physical world is not yet ready to provide such updates. By managing user expectations, you can deliver supply chain that achieve consumer satisfaction and not burden your IT team.
Ever encountered dead codes and processes? I have been cleaning many of such dead codes and processes. Usually, these happens to system that have been around for more than 5 years. Dead codes and process are usually system features that users no longer required or understand. These are some quick approach to handle them for removal.
Happy Path Approach
When you upgrade an old system to a new one, you should first plot the happy path. In daily operations, 80% of the system usage are on happy path, 10% on exceptions and the rest are manual handling. Using happy path approach, your system migrates all the key essential functionalities. This way, you can also clean up the dead processes and its corresponding codes.
Users compartmentalise system usage in their thought processes. As times goes by, fanciful nice to have features are forgotten and languish in neglect. Querying uses on these features will get a response of “I don’t know”. As a rule of thumb, these features are considered “dead” and can be removed with no impact to existing system.
These dead codes and processes often results in degrades of system performance and unnecessary costs in support tickets. Thus, it is a good exercise to clean up dead codes and processes when you are upgrading your legacy system.
I had a meal at MacDonald today and observe that the role of cashier have been eliminated in this MacDonald branch. In place of it, self service kiosk are present. You can now even get your meal serve to you via table service. This gives a pleasant customer experience beside the quick and fast food meal we know in MacDonald.
Self service gives customer control of their experience in the purchase of services and goods. This reminds me of scenarios where users claim that these tasks are too technical and refuse to self service. The model is nothing new and exist in early days like ATM and kiosks. Jobs will be remodel and those who refuse to change will be obsolete like the cashier role in MacDonald.
By participating in self service, consumers are invested in their own experience. This also creates loyalty and trust with the products. All these factors give rise to higher consumer satisfaction. This model can be applied for all systems. Digital transformation is the trigger to change and enhance customer experience instead of requirements fulfilment. Products and services are reaching a saturation point that customer experience is the differential factor.
Job remodelling will continue for next 5 years in tandem with digital transformation. It is either to embrace or be eliminated. There is nothing 麻烦 “troublesome” as these are the facts to be.
Localisation is a key component of TMS (Transportation Management System). Legacy system suffers from language localisation partly due to database design which forces the implementation to be encode in certain locales. Globalisation of application creates new solution architecture which default localisation. One of such settings is the configuration of languages and display text.
One may think languages in system is pretty straightforward. However, to a system, English does not literally mean English? Due to complexity of languages, we seek some sanity to classify languages in system. One of such classification is ISO 639. However, this is not the standard adopted by system due to different computer organisations. For instance, Windows language encoding will vary from that in Linux. The application SME (Subject Matter Expert) must be familiar with language localisation encoding across various platforms.
Future Language localisation
At present and in near future, we will see NLP (Natural Language Processing) gaining popularity like Chatbot. There will be focus for system to localise naturally from user behaviour and geolocation. Translation are real time and ML (machine learning) driven. Data locales are no longer required as data can be stored as what it is and translated as such.