While developing a Chrome translation detection I came across a weird Chrome behaviour:
When a page is translated by google, quite often it is not possible to type text into input fields on the translated page. With normal text fields, text may be shown in reverse order. With password fields, no typed chars are shown (so the * representing a char). When I switch back to the original language, all of a sudden the text is shown, so Chrome seems to save it somewhere but just does not display it.
Sometimes the language is not detected correct, so I use the "This page is not in ..." functionality of Chrome to set it to the correct value. This seemed to be the reason for this strange behaviour in the first place. But after quite a few tests, it may not be the problem. In both cases (with setting the correct language or not) it works sometimes, but ore often it does not. I could not find a pattern so far.
This happens on other computers of other people as well, so it does not seem to be a problem with my computer.
It is a page developed with Vaadin and Spring and the page this came up was the login page. I use the LoginForm functionality of Vaadin, so maybe that's a possible reason for this behaviours. I tested the translation on other pages with input fields as well, and there it seems to work. But I'm not sure if this isn't just Murphys law.
Anyone any idea about this?
Related
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.
I'm working on a document-editing application using CKEditor, where the user can open multiple documents side-by-side in a pair of editor instances.
Most of the time, the user will be editing two different documents, but it's also possible that the two editor instances might contain different views of the same document. That makes things tricky, since I'd like to changes in one editor instance to be immediately reflected in the other instance.
Without hacking the CKEditor core, is something like that possible?
If not, would it be possible to write a plugin that would provide that kind of functionality?
What about if I was willing to get into the core code and hack around a bit? How difficult would it be?
This is a very similar case to a collaborative editing like Google Docs allows. The only differences are that you won't need to synchronize this via network and that it's very unlikely (if not impossible) that the same documents will be modified by two users at the same time. This makes things simpler... a little bit.
A year ago me and my colleague (we are both CKEditor core devs) took part in Node.JS Knockout and our plan was to create a collaborative editor based on CKEditor. It was only 48h, so the result is not impressive, but it worked. The source code is here.
The main problem you'll have is applying changes from editor A to editor B without breaking a caret position in editor B. Basically, you cannot just take data from editor A and set them in editor B, because everything in editor B will be reset including scroll position and caret. Unless this is not a problem, but I assume it is.
So you would need to:
either find a nice algorithm for extracting changes (like diff, but working on a DOM tree, not an HTML string) made in editor A and an algorithm to apply them to editor B (and this is what we implemented on Node.JS Knockout),
or find a way to guess caret position after resetting data in editor B; for example you can remember the caret context in editor B before setting data and try to find it in data that will be loaded.
Both ways are doable, but the first way will give better results if you'll implement it well. However, if your you don't know enough about DOM and contenteditable, then this task may overwhelm you. In this case I would advise to block possibility of opening one document twice.
I have the following issue, concerning the way to fine control Japanese input in an iOS app. To make things clear I include an image to this post (see below).
As one can see I have typed や in the input text field and a bunch of choices (や 役 矢 訳 ヤ 屋 焼き …) appear above the keyboard for possible conversions.
Here is what I would like to know:
The choices presented in the picture make no sense for my particular app. I would like to be able to set myself the possible conversions offered to the user.
In this case it would be (山形県 山口県 山梨県). Does anyone know how I can achieve this?
In other words I am trying to find out how handle the set of data appearing above the keyboard.
Thanks in advance for any relevant information.
I am trying to debug a tricky situation with auto-correction not getting correctly handled in a TextBox, but I am stuck:
I cannot find how the tapping of an auto-correction suggestion in the SIP gets communicated to the TextBox.
I have traced the KeyUp, KeyDown, TextInput, TextInputStart and TextInputUpdate events, but they do not seem to be involved in the update of the Text in the TextBox object.
Background:
When a language other than Greek is used, auto-correction works as it should for a TextBox in my app. However, when the language is set to Greek, nothing happens when tapping on the suggested word ... On the other hand, in TextBoxes in standard phone apps (e.g. adding text in the Notes section of a contact) Greek auto-correction works perfectly. So, my first guess is that there is something wrong with the TextBox rather than with the SIP. My plan is to subclass TextBox, modifying only its auto-correction handling parts.
Any help would be much appreciated,
Gerasimos
Update:
I made a few tests and this seems to be a problem in all non standard apps. Specifically, I tested the eBay and SkyMap applications and in both cases English auto-corrections work, while Greek do not.
The problem is easy to reproduce:
put a textbox in an application (with an inputScope that has auto-corrections enabled)
use a Greek keyboard layout
tap 1-2 random letters.
tap on one of the proposed auto-corrections. Only the final space is introduced, and in cases that the cursor is between two spaces (as I preferred to test it) nothing happens.
So, I believe that there is a bug somewhere in the framework part and not in the application code. Now, if we could find how this auto-correction tapping is communicated to the TextBox... :-)
You should not be able to interrupt the SIP directly, You can edit the content of the textbox after the value has been entered/changed. Alternatively, you can implement something like an autosuggest if your intentions are to change the content instead of the visuals.
I have an application that displays a dialog when the user needs to enter information. The reason for this, is to keep the main form readonly, and only when you need to add/edit data will a dialog appear.
The problem I'm wrestling with is what to display for the label names in the dialog. The application is a WPF desktop app and traditionally desktop apps are very short on label names (usually one or two words). I want to make the dialog user friendly and be more descriptive about the information that is required. Web developers seem to be catching on to this and are much more descriptive with their label names, but most of the forms I've looked at are forms that are only filled in once, whereas I will have data that can be edited.
An example: If I had a label that asked a user if an employee smoked, in most a destop apps the label would normally be something like 'Smokes?' with a checkbox, whereas I want something like 'Does the employee smoke?'. My issue with this is, that the first time you come across this dialog and enter the data, then it seems OK, but what about when you are editing data that is already there. Does this label now make any sense. Past tense and present tense seem to be getting in my way and I was interested in what people think or ways they have approached this. The application I'm writing is a WPF app and I feel that traditional label names are a bit old in the tooth now.
Another example would be entering contact details for a person. Do I just have labels that say Phone, Fax, Email or something more descriptive. i.e. a label that appears before the textboxes stating 'Enter the contact details below' and then the single word labels?
Maybe I'm just being pedantic about all this, but I would like to take a step forward so that my application contains more than single word labels that are sometimes unclear to the user about what is required.
Why not make use of the concise labels and use Tool tips for a longer explanation.
The longer explanation is only required when a user is unfamiliar with the application anyway.
Also, you could re-word a label to make it sound more like a question such as "Is a Smoker?"
Since you are using Stack Overflow, take note of their use of tooltips, I think Jeff Attwood has a blog post or comments in a podcast about the use of tooltips in SO. I can't remember where I heard / read it.
Have you thought about creating a "quickstart" flow or wizard for entering data for the first time? This would give you the opportunity to guide the user through the process, using labels with descriptions, so that they learn to associate the description with the label you've chosen (hopefully something succinct but intuitive). Then when they need to edit data, they have learned the application taxonomy.
If you are running into issues with tenses, steer clear of using verbs or only use the present tense. I would try using nouns - "smoker?" instead of "smokes?"
When you're asking for common data like phone numbers, email addresses, you can probably assume that the user will understand what you mean. Just be clear as to whose contact information you are asking for - using a title for the field set that is explicit is a good idea ("Employee Contact Details"), adding a short description above the field set will help too.
Of course, you should always do some level of usability testing on your application before you launch it to uncover any issues with the interface.