Wednesday, 12 October 2011

Cowon and UCI design

한글을 보고 싶으신 분은, 영문 위에 마우스를 올려 놓으십시오.

Cowon is without doubt my favourite PMP and mp4 player manufacturer. The company has not disappointed even once since the first time I heard of them which was back when the iAUDIO 4 was selling furiously well. Having been influenced heavily by a friend, I got the Cowon G3, my first mp3 player which I still keep and use from time to time. Acquiring the D2 and J3 in the following years did not require any difficult decisions as can be seen from my reasoning below.



iAUDIO F1 - This intriguingly designed mp3 player sported a F1 car design with 2x3.5mm jacks as exhausts and a speedometer GUI.


Devices which were made by Cowon have always had a common set of specification differences to all other mp3 manufacturers:
  • Superior and honest battery life
  • Good sound quality
  • Support for almost any (audio) codec
  • Durable design
  • High pricing


The high quality has since made Cowon the leading company in mp4 manufacturing in Korea and has allowed Cowon to have a certain amount of international recognition as well as love from non-iPod communities such as anythingbutipod. Currently there exists a 'cafe' or forum dedicated to Cowon's MP4 players boasting a member count of about 600,000 Korean users. For a small country with a population of approximately 50 million, this number is staggeringly large. There also is a dedicated overseas community known as iAudiophile.net maintained by fans of Cowon's products featuring the latest content from modders and designers as well as casual users.

While the build and sound quality of all Cowon devices are great and have catapulted the company above most other non-iPod competitors, there is one aspect which has been criticised from time to time, the graphical user interface. This has been dealt with skilfully by the introduction of User Created Interfaces (UCIs).


The introduction of UCIs



A 'hacked' user theme named 'iTouch' by Fishfutter


UCIs were first introduced for the Cowon D2. It was a proper success and user created flash interfaces sprung out everywhere aided indirectly by Cowon's own UCI contest. The UCI implementation was somewhat lacking. There were only a handful of FS commands which could be called, the backend was seriously outdated and thus used Flash 7 which relies on Actionscript 2.0 but has less features than Flash 8. Even more frustrating was the lack of persistent data storage support and music indexing support which skilled UCI developers circumvented in various ways. The music UI was the only customisable UI as well and the only other way to change the look of the overall UI was to 'hack' a resources binary into the player with substituted images.

Sense by Kizune, a Music UCI for the S9, J3, X7 - One of the most popular UCIs in existence currently

The release of the Cowon S9 brought about many changes to the UCI front. Full UCI support for every bit of the player was supported with documentation. Persistent storage via FS commands and shared objects was supported and the number of FS commands was increased many folds to allow for a 'Full UCI support'. This meant that one could now edit EQs, change every single setting and create whole new widget sets by simply knowing how to design and code using Adobe Flash. This was not without woes however. UCIs tended to take up more memory and therefore were slower than the stock UIs. Interfacing with the firmware was still done via raw FS commands and code sharing was not common at all in the communities which meant that some UIs were less optimised and therefore slower to load and run.

For the users this did not matter at all and many Cowon product users thereafter (J3, X7, i9 and now the i10) could make use of the many attractive user interfaces which many skilled flash developers were churning out. The UCIs truly helped towards extending the feeling of 'hype' for the users' new players and added a certain freshness to the players for every UCI release. By handing UI design choice to their users, Cowon had been able to shift the load of updating and satisfying users to the community, at least partially.

The developers however had to face the frustration of careful and tedious optimisations. This was because the only tool Cowon had provided was the list of FS commands, a short guide about the software structure, and some badly written sample UIs. Some readers may be questioning how I am referring to the UCI samples as 'badly written' since the stock UIs run well. This is because the UCI samples do not get updated and the code is barely legible and is not object-oriented.

The way I see it, UCI designers, and I repeat, designers, should not have to deal with tedious optimisations as well as direct usage of FS commands. Even today, most designers are having to use Cowon's sample UCIs to create their versions by modifying the code. The usage of raw FS commands which can be found in every bit of the code often requires that one truly understand when a certain call should occur and which values should be updated. Often this is not the most simple matter, requiring hours and hours of plugging and unplugging the mp4 players while modifying and re-arranging code. Since the code is not object-oriented and non-modular, one always finds himself/herself getting rather confused with bits of code ending up here and there.


UCI Framework

The solution I have for this problem is the introduction of a so-called 'UCI Framework'. I envision a set of actionscript scripts which can be #include-ed in a modular fashion to enable access to objects and methods which allow UCI designers to simply flick the switch without any worry or hassle. One would not need to worry about how the repeated usage of certain FS commands would impact their UI's performance. Statistics and values of certain settings should not have to be retrieved from slow FS command calls directly but would be cached and updated internally. Designers would do what they can do best, designing and writing code for lavish effects aimed both towards ease of use and visual appeal.

Now I admit that I am in no way an experienced Actionscript 2.0 developer, nor have I been part of creating truly complicated UCIs. However, I have encountered numerous situations of frustration which I hope future designers will not have to deal with. Also, there are many skilled developers who are still toiling daily without any incentive for the better experience of the users. These developers have the know-how and experience with dealing with Cowon's players in the most efficient manner.

The acronym UCI is commonly mis-interpreted as standing for 'User Created Interface'. In the most strict sense, this is definitely true and Cowon itself has introduced the term years ago. I would however like to use a new acronym, 'CCUI', 'Community Created User Interface'. Of course, 'UCI' is an easier acronym to use and is definitely what all users will identify custom flash interfaces as. My point is not that the acronym should be changed, but that the approach to UCI design should be changed. Code should be shared between developers as well as know-how. Afterall, surely this would allow for more designers to actually 'design' various interfaces instead of giving up after months of hard labour. Would open-source contributions prevent your own UI from gaining more popularity? Would spending time on helping the knowledge and skill-level of the general developer community rise affect you, the experienced UCI developer negatively? I think not. There may be style differences and there may be philosophy differences but surely getting the annoying and tedious bits out of the way would let you do what you can do best?

For the reasons I have mentioned above, I would like to propose a community-created effort to code a UCI framework for current and future Cowon flash interfaces. I myself will be aiming to release a basic version for all developers to make use of and edit in the following months hoping to spring off a truly community created base for designers who would gladly not deal with the efficiency problems. A post will be written in the future to outline the features and philosophy of the framework to aid the understanding of anyone who is interested in using or working on the framework. The general aim is to be able to provide simple control based on objects as well as some heuristics for features such as device identification and millisecond seek positions.

In the meanwhile, if any of you flash developers have any suggestions or ideas, please do comment below (you do not need to login) and express interest.

(While I claim to know much about what I have written here, I really do not so please feel free to correct me on various bits and pieces!)