User:Planemad/Work/log

16-20

 * Getting started on translation workflows. Familiarizing myself with the features of translatewiki and the mediawiki translate extension
 * Questions in my mind before I dive in: what do people refer to for technical vocabulary in their language? can a person fluent in only one language contribute?
 * like any wiki, as a newcomer I am lost. If only there was a shiny button that said 'start here' and gave a nice overview about what is where and how the wiki is organised.
 * and also a dictionary to lookup commonly used jargons - "The primary language doubles as your interface language on this wiki and as default target language for translations", "assistant language" . I want to translate from english to tamil, I have no clue how to set this up.
 * There is only 1 layer of message grouping, why not Projects>Message groups?
 * Finally! Help in the corner.
 * There lacks a priority metric for language and projects that would tempt me to make an effort to translate a very highly used and important message.
 * Translation starts from here. It only looks intimidating from here onwards
 * Unexplained tabs - what is proofread and translate? and when do I use it?
 * Verdict: There are just too many tables, action buttons, hidden interactions, cryptic messages and colors for me to make sense of it. This is a complex interface with a steep learning curve that would appeal more to technologists rather than linguists who should have been the focus.
 * Will need to observe an experienced translator using the interface to figure out quick fixes and improvements. It does feel like the mediawiki framework is a limitation to implementing a more optimized interface.


 * Attending my first sprint meeting and getting a hang of how things will be working. Agile requires quantifying work, but how do you quantify design work? I have never measured my wok on any scale before.
 * So far so good, I'm tasked with just enough to keep me busy for the next two weeks.
 * Sprint goal: Usability study of the existing mediawiki translate extension running in translatewiki, Mockups of the Universal Language Selector


 * Reviewing a UI proposal for improving the translatewiki workflow
 * Proposal is essentially another level of nested tabs which makes it a lot easier to drill down to a specific project or language.
 * Functionality wise, an improvement over current methods, but will definitely add to the visual clutter and confusion on how to navigate the site. Two levels of tabs is not a good idea.
 * Overall, while the idea itself is good, it doesn't work when placed into the site with a lot of other tabs and controls. Further simplification with a holistic view and removing redundant UI controls is needed.
 * Looking at a high level information architecture restructuring. Time for whiteboard sketching time.
 * I can suggest a bunch of quick fixes, but is it more worthwhile to work towards a long-term vision that will require major software changes?


 * Diving into translatewiki, having a look at ui bugs filled and support feedback
 * Liquid threads is a bit of a pain to navigate around and find things. If there was a little filter that would remove messages with less than X replies, I would be seeing a lot more important topics. And ofcourse, a filter by date range. There's a lot of feedback in support, but virtually inaccessible forever.
 * feedback: users want to translate into multiple related languages at once (english, simple-english)
 * 36006 a warning if a user accidently closes or leaves a translation task so that data is not lost
 * 18721 hide irrelevant languages from the user
 * It seems a little strange that you can translation editor becomes a popup when you click the link, or opens inline in the table when you double click. Is there a reason for both to be there? which one is more effective?
 * The inline editor has the advantage of being in context and quicker to step through messages. If it could be invoked in a single click, it would become even faster! if the controls are switched, and people get used to the inline editor, the popup can be discarded alltogether
 * Some of the issues with the inline editor is that it loads slowly and also changes the page size/scroll bar since new content loads in place.
 * I'm trying to come up with rules for a site interaction diagram that can describe any site's workflow and user tasks visually. I haven't seen any existing one that is good. Will really help developers and designers understand how the site actually works and how the user interacts with it. Will need to park this for later.


 * I've got the first look of rough sketches for the ui of the ULS from User:Pginer, the interaction design expert in the team. I'm going to start 'digitizing' it so that the team can discuss various options and pick the best combination.

http://etherpad.wikimedia.org/planemad