Thank you for your patience as we continue to improve the user experience.
Noticeable Changes
Aside from the display fixes, there are a few small updates that you may notice.Feature Improvements
- When adjusting the top or bottom of a column in the parsing tool, lines clipped off will be removed automatically. If transcription data is at risk of deletion, this must be confirmed.
- When adding, deleting, or merging lines in the parsing tool, T-PEN will attempt to keep your place on the page, even if the line you had been working on has changed.
- Clicking on a line within the Preview Tool will navigate to that line on the page.
Changes to Animations
Part of the fix for recent troubles included disabling the transition animations on the main transcription area when moving in and out of tools. When moving from a small line to a much taller line in the transcription area, you may see the workspace jump as the image moves. Interacting with tools will also split the screen or return to full size immediately.The T-PEN Solution
If you are the type who loves the details, here is what we discovered in fixing T-PEN.The Struggle to be Invisible
Our interface is helpful because it only shows you what you need to see. CSS3 transitions are a handy way to move what the user needs in front of them to do work. Earlier this year, browsers updated to support the emerging standards. As browsers such as Chrome, Safari, and Firefox quicken their development cycles, small changes to the handling of these items appeared - even between platform cousins like Safari and Chrome.In our case, visibility was the wrench in the gears. To allow users to focus on the textarea for each line as if they were just moving through a web form, T-PEN does not hide them using display:none, but with visibility:hidden. Though visibility is listed as a supported property by CSS3 transitions, it was managed a little differently by some browsers, so opacity:0 was used as well. This worked well and allowed for progressive enhancement, as the failsafe would simple show the element immediately.
Around March, however, some browsers began to manage transition:visibility .25s, opacity .25s a little differently, disallowing .focus() until the element was completely visible, but still allowing it to become the activeElement. Others remained with the default behavior of either failing safe to the end state immediately, or changing the access rules for the element before animating the transition. It is critical to the T-PEN interface, that only one line is focused on at a time, since the image positions and workspace location rely on embedded data built into the user's intended focus.
Safari failed the most spectacularly, refusing to render any textareas visible on pageload and requiring brute force to encourage normal behavior. Though several developers had complained about similar behaviors, no definitive reason could be found.
Firefox took the approach of a death of a thousand papercuts, displaying the page nearly perfectly, but refusing to place the cursor in the next line, leading to unintended additions to previous lines and necessitating a mouse click a the beginning of each new region.
Chrome grew it's own personality, behaving slightly different in different installations. Some saw no problems, while others would lose the cursor at each line. Worse, if a user continued typing without proper focus on one machine, they would see the first character they typed on the previous line before the focus would catch up - on other machines, there might be several characters.
Once this inconsistency was finally illuminated, several other bugs were traced back to different handling of transitions. For this reason, the height and width animations for some main layout elements has been disabled until the implementation can be adapted or the standards support has stabilized. Specifically problematic were cases where height and width were animated with different durations.
No comments:
Post a Comment