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.
 * I was getting lost with all the etherpads floating about in the team, and asked for an etherpad of all etherpads, and here it is!.
 * Always fun to get inputs directly from the community and find out what drives them. Useful feedback sessions from translatewiki:User:Shanmugamp7
 * Because the inline editor is activated by double clicking a normal looking table, people dont seem to be aware of it
 * Translators have preferences for translating messages of projects of their interest
 * There's more support for inline editor since the previous translation can also be proofread and the position is maintained. If the loading speed can be improved and it doesnt alter the page height, this should be the default behaviour.


 * Created the first bunch for wireframes for the ULS proposals, will need to update and add annotations over the weeek L10n-ux-Universal Language Selector-Wireframes1.pdf

23-27

 * Did a user observation of twn leader and translation champion user:siebrand to see the translation workflow at its fastest speed
 * siebrand starts of by opening a favourited url directly
 * the workflow is dependent on a lot of clicking on tiny and hidden targets
 * his goal seems to be translating everything he can to dutch. i can understand his obssession, similar to me mapping whatever i can on openstreetmap.
 * !!FUZZY!! is a flag to denote a change in the original message. making it a checkbox would save the effort of erasing the text manually
 * hotkeys are required for everything in the translation workflow, clicking little arrows and buttons, double clicking tables, scrolling are a pure waste of time
 * the search form needs an overhaul, you need to read the fields and try multiple combinations to understand how it works
 * google tanslate looks like a common reference even for the experts. why not just provide a link to it that opens in a new window?
 * since the microsoft translation has been integrated into twn, it only makes sense that the system is in turn learning from the translations and giving better suggestions over time. must dig more on this
 * siebrand was not using hotkeys while translating, the reason was that clicking using his touchpad was fast enough. after making him use the hotkeys for a few minutes, he seems to have switched to hotkeys for good


 * a smart language ordering algorithm for language lists. technically challenging, but would make language selection a lot more relevant:
 * interesting discussion with Pau on metrics for evaluating usability
 * began making interactive prototupes for the uls screens, the initital plan was to striing to gether static screens and make an interactive pdf, but with the different language scripts html is the way to go
 * I have always shied away from js, this is a great way to learn and build something useful at the same time
 * jquery is the best, over the weekend, I have graduated from having never written js to be able to write functions to add interactivity
 * an interesting take on destroying greys and low contrast in type
 * the uls has me itself confused, there seems to be too many use cases and combinations of what a user might expect and how the selector will behave.

More

 * Current tasks and sprint status of the L10n team (login: guest/guest)
 * http://etherpad.wikimedia.org/planemad