Could you please first introduce yourself?
I am a senior UX designer with 15 years of experience working at a telecommunications agency and I designed many of the agency’s apps, other related websites, and membership sites used to view telecommunications fees commonly used in Korea
Could you explain about your work?
I must create a lot of mobile apps since I work at a telecommunications agency. They must cope with various kinds of devices. Apps for hobbies such as SNS can cope with a few devices such as Samsung Galaxy, and a few devices of LG, but for telecommunications’ company’s apps, that’s not an option. [It is practically impossible to cope with all the various devices available in the market, but at the same time, this is a necessary thing to do. The resolution ranges from 320 to 1920, so work is rather difficult. However, the situation recently improved.
How did it improve?
It got better after I learned about Namo WebEditor ONE. To be honest, most mobile GUI designers devote nearly all of their working hours to creating specification documents. We have to work with developers which mean we need to spend a lot of time creating UI specifications, screen guides, and other documents that the developers will look at. Designers don’t just design but also continuously create documents.
It’s not that there aren’t any solutions to this problem. If a developer works with a designer one-on-one, the situation is a little better. However, it is difficult for this kind of environment to be created, realistically speaking.
Another solution is that designers only create the PSD. Then, the developers would use these PSD files to cut images and insert into CSS. But this solution, again, is realistically difficult.
What did you do?
There is really only one conclusion. What we designers make must be converted into code. That then needs to be handed over to developers for development. At first, I tried using the prototyping tools in the market. Ionic, Framer etc. were all no use.
It cannot be prototyping but actual codes that developers can use>. This was my conclusion and I used 50 different kinds of tools and none of them proved to be satisfying. Two were somewhat okay. One was Just in Mind and the other was Antetype. However, these two tools were not enough. It needs to follow the method of companies in terms of widgets or documents but these tools did not.
And then I got to know Namo WebEditor ONE.
Of course, there is a learning process in implementing Namo WebEditor ONE, such as learning a little bit of HTML or CSS. For example, Namo WebEditor ONE uses coordinates such as Absolute, Relative, and Fixed which are the same in CSS. As long as you have such concepts in mind, there will be no obstacles.
However, before this web frontend is implemented, the issue of native or hybrid must be solved first.
Indeed, ‘Hybrid vs. Native’ is a never ending debate in the industry
For mobiles, many companies will be better off with native development. But creating many native apps requires a lot of work. Due to the nature of the telecommunications industry, if a new device is released after we finished all the work, we must go back and make sure that everything copes with the new device. If it is a hobby app or an SNS app, we can simply say “We do not support that device”, but not for telecommunications apps. These apps are necessary so it must be supported by all devices. But this process is much too difficult.
Anyone who has done android development and maintenance in the communications or finance industry will know this to be true. Sometimes, it is difficult to know whether we are a telecommunications company or a development company. This led us to believe to go with hybrid and at first, the performance issue was a big worry. But now, it is okay.
After I started using Namo WebEditor ONE, the hardware performance improved. The device is now running the animation in hybrid at a high speed, and yet it holds fine.
For what we recently created, we linked Namo WebEditor ONE to React-JS and there was no noticeable difference with the native one. It was in fact, even faster. Video portals were previously made by hand at the frontend development stage, but Namo WebEditor ONE linked to Angular-JS showed better performance. When we noticed this, we decided to go with hybrid.
You seem to know quite a lot about development. Do you not find working with developers difficult? Communication between the designers and developers are usually very important for work.
Yes, a little bit. When we were first given a project using Namo WebEditor ONE, our UX team did not even know that HTML or CSS could be separated. At first we just read books that explained HTML basics. In those books, CSS were not separate files but rather a part of HTML files as styles. We all thought that’s how it was done at first. Then after looking at Namo WebEditor ONE’s products, we learned about the separation of CSS. And from this, we created exterior files for any extra CSS needed then integrated it using this tool. We then tried integrating exterior Java scrip libraries. That is why I thought that I should learn a bit about Java script. I only know how to handle a little bit of jQuery.
Is that what everyone does?
When team designers create and bring Namo WebEditor ONE files, we set the format and organize the class names again; the dashes created with Namo WebEditor ONE files and such. Then we run the same copies, then the regular expressions to reduce the number of classes.
How did you learn even regular expressions?
At first, everything about making the CSS more pretty and presentable was done by hand. I have never learned anything about development. Then one day, I learned about regular expressions and it seemed like a revolution. I tried it and it was great. But sublime texts could not save regular expressions. I came across an editor BBEdit later and this had regular expressions saved. I then ran regular expressions on CSS sources from Namo WebEditor ONE to edit the CSS before handing them over to developers.
Currently at developing companies, I am certain that with my designs and publishing, it is at least twice as faster than hand-publishers – except the script. I have made over 50 commercial pages by myself in less than a week. Using tools certainly increases speed significantly. There are 5 media queries per page ranging from 320 to 1920.
Is this all thanks to Namo WebEditor ONE?
The first result I saw happen by using Namo WebEditor ONE tools is that I was able to get rid of screen guides and UI guides. Another effect is that with the prototyping feature, I can instantly view whether a development code is used or not. It takes a lot of time for developers to create and provide a test version. But for us, we are working on prototyping at the same time. We hand over the codes that have finished the prototyping process which decreases the design time by more than half.
What happens when faced with version control? If the design or planning changes while the developers are developing, they would not be happy with that.
That is why I commit on git before handing it over to developers. There are many services such GitHub these days. Every time there are any changes, I would commit which gives me a diff. I save that diff part as a PDF file and hand it over to the developers at the developing company.
Namo WebEditor ONE is certainly better in terms of maintenance than ones created by hand. There are a couple aspects. Firstly, when done by hand, the CSS self-multiplies. All previous sources do that. CSS can be added but can’t be deleted. When you edit this CSS, you can’t guarantee what will happen in each situation but when you use tools, the result can be anticipated easily.
I guess that’s because CSS is such a complex and difficult coding.
For complex pages, we have over 10,000 widgets and there are hundreds of these pages and maintenance by hand of all those pages is very difficult. I believe that even for subcontract designs, Namo WebEditor ONE is a better idea than PSD.
I do believe that being able to handle frontend as a GUI designer is a huge advantage.
Designer creates even CSS, sometimes even jQuery… This is why I decided to implement Namo WebEditor ONE. Namo WebEditor ONE creates even a widget set in jQuery which I can save as my custom widget and continue to use over and over again. This created unanticipated positive results. Usually, each time a maintenance process is done, the CSS would increase. But with Namo WebEditor ONE tool, CSS is deleted along with the widget which keeps the code neatly organized and cleaned.
Many designers may think that “that’s not my job” about such issues, but I believe that it allows the designers to be able to focus on the project better.
Focusing on making PowerPoint documents is not what’s important. Creating guides after the photoshop design, uploading them to mobiles immediately, cutting the image then running it on smartphones to check in order to edit it right away is what’s important.
I believe that not spending too much time creating UI guidelines, but focusing more on the design quality, therefore, the essence, is what is most important.