So the problem is that I want create such an idea. There are a table and a sheet of paper (just a Plane). I want to place some text on this sheet of paper. I read about Text Mesh and I thought that I would use it but I had a problem about it. I need to limit my text on this sheet of paper but I haven't found any borders I can place there. How can I set borders to Text Mesh? Or are there any decision I can use to handle this situation?
TextMesh does not have borders
Instead, you are probably interested in a World Space Canvas and using UI text instead. Unity has a great tutorial in the manual for setting up a world space canvas, which pretty much amounts to "set the Canvas to world space, decide on a resolution, decide on a in-game size, and position it."
For text, you actually have two options: UI Text and Text Mesh Pro. TMP used to be an asset on the asset store, but Unity has integrated it into a semi-standard package now (just create a TMP object and you'll be prompted to do the importing). TMP has several additional features and options that standard UI Text does not have, including in-line sprites, margins, text alignment, better rich-text, and so on. It might be overkill, but it is available.
At work we have a small external consultancy which don't appear to have much UX/usability experience. For example, their primary approach so far to responsive design has been to have a mobile breakpoint for font sizes (usually expressed in px, to boot) for heading tags, and nothing else. Even text scaling is a foreign concept to them.
We are going to release a new forms system, and they've submitted mockups of what they envision for the form look and feel. Besides the obviously faulty approaches of using placeholder text as labels, floating the label above the form when a user clicks in it, etc., their least poor mockup has each field with the label floated to appear above and inside the field boundary.
With this approach, padding is used to slide the actually enterable portion of the field down. The field boundary in this particular case is a non-gray color and with rounded corners as well. The net visual impact is of a visual bounded region with no visible field inside of it, and a label inside the top.
For dropdowns, there is however at least a visual cue that there's a field there: the down arrow. Still, where a user would expect to see field boundaries, there are none.
I'm a little concerned at this and not sure how to raise my concerns. A/B testing of this before a full release isn't possible currently, or I'd go there. Politically, my boss's boss loves these consultants, so it'd be dicey to simply express concerns without something to back them up.
I see a lot of studies and blogging about rounded vs. square corners, with studies showing that rounded corners can be more inviting and square corners draw more attention. But here, the concern I have over rounded corners is that, without any other visual cue that "here is a field", the rounded corners and the label inside and at the top directly communicates, "This is NOT a field but an empty region". Is there research or other support for this?
I'm writing a iPhone app that needs to render i18n text that includes diacriticals (tildes, accents, etc.). Apple provides the UIFont class which can be used to get a given typeface/font-size combination's leading, ascent, descent, etc.
The problem is that this information does not accurately reflect diacriticals. Specifically, diacriticals on capital letters often exceed the lineHeight (the UIFont property formerly known as leading).
The same problem exists throughout the frameworks, ie. NSString:sizeWithFont has the same issue.
I need to know the true bounding box for text as I am using OpenGL which does not have text drawing support and therefore requires rendering text to a texture.
Currently, I'm using a hack to get around this issue. Is there a better way?
It's not possible with NSString, since it just returns a size. You can try CoreText which seems to support returning bounding boxes, but that's a bit overkill.
It's a difficult problem when Unicode supports things like è̀̀̀ (see also: zalgo); things can render above the top of a line so you can't just draw the characters. Some text-drawing APIs make you specify the baseline and give you the bounding box so you can get both ascenders and descenders, but UIKit doesn't do this.
Then, you have crazy cursive fonts with the occasional huge ascender. It's unclear how to handle these either.
The lazy way is to render to a texture with margins at the top and bottom (0.5 lines? 1 line?) and not care too much about the extra overhead of some transparent pixels.
I haven't looked at CoreText much, but it doesn't look particularly promising.
Please pardon my lack of Photoshop skills, but I'm curious what type of strategy Apps like Facebook and AP Mobile News are using for the 'label slider' in their applications. Here's a quick snippet outlining what I'm talking about as I'm sure the name I'm labeling the utility as is being butchered: http://dl-client.getdropbox.com/u/57676/slider.jpg
Essentially the user can touch the label and glide it along the X axis. It has a smooth bounce effect also once it hits the edges. This gives quite a bit more real estate if you need to present more on the screen than what your portrait mode allows for and is thus very valuable.
Is it a matter of just creating a UILabel that's wider than the screen with a bit of Touch API + Core Animation? Would love insight on how to start tackling this thing.
You'll most likely want to use a UIScrollView, with a UILabel as its content view. Size the label appropriately to your content, and then set the contentSize property of the scrollview to that size.
I created a similar control, and it's much easier than you think. It's just a UIScrollView with a series of UIButtons added to it. You could use labels instead of buttons - just depends on the feel you want. I think Facebook is probably using labels for theirs.
In any case, you'll probably want to use a series of components rather than one component (which is what Ben suggested) in the event that you want to, say, style the "selected" label differently from the others. It also makes hit detection a little easier.
You get the bounce effect for free by default - you may have noticed that most scroll views in iPhone apps do the same thing. It can be turned off as well.
I'm starting a new project which involves developing an interface for a machine that measures wedge and roundness of lenses and stores the information in a database and reports on it. There's a decent chance we're going to be putting a touch screen on this machine so that it doesn't need to have a mouse or keyboard...
I don't have any experience developing for full size touch screens, so I'm looking for advice/tips/info from you guys...
I can imagine you want to make the elements a little larger than normal... space buttons out a bit more.... things like that... anyone have anything else to add?
A few things to consider:
You need to account for parallax error when touching controls. Basically, the user may touch the screen above or below your actual control and therefore miss the control. This is a combination of the size of the control (eg you can have the active area larger than visual control to allow the user to miss and still activate the control), the viewing angle of the user (which you may or may not be able to predict/control) and the type of touch screen you're using. If you know where the user will be placed relative to the screen when using it, you can usually accommodate this with appropriate calibration.
Depending on the type of touch screen, you may need to ensure that your users aren't wearing gloves or using an implement other than their fingers (eg the end of a pen) to touch the screen. Some screens (eg those depending on conductance) don't respond well to anything other than flesh and blood.
Avoid using double clicks because it can be very hard for users to reliably double click a control. This can be partly mitigated if you've got experienced/trained users working in a fairly controlled environment where they're used to the screens.
Linked to the above, if you are using double clicks, you may find the double click activated when the user only wants to single click. This is because it's very easy for the user's finger to bounce slightly on touching the screen and, depending on how sensitive the double click settings are, trigger a double rather than a single click. For this and the previous reason, we always disable double clicks and only use single clicks (or similar single activation controls).
However big you think you need to make the controls to allow for touch activation, they almost certainly need to be bigger still. Make sure you test the interface with real users in the real deployment environment (or as close to it as you can get). For example, we deployed some screens with nice big buttons you couldn't miss only to find that the control room was unheated and that the users were wearing thick gloves in the middle of winter, making their fingers way bigger than we had allowed for.
Don't put any controls near the edges of the screen - it's very hard to get your finger into the edges (particularly if the screen has a deep bezel) and a slight calibration problem can easily shift the control too close to the edge to use. Standard menus and scroll bars are a good example of controls that can be very tricky to use on a touch screen and you should either avoid them (which is preferable - they're not good for touch screens) or replicate them with jumbo equivalents.
Remember that the user's hand will be over the screen, obscuring some of the screen and controls (typically those below where the user is touching, but it depends on the position of the user relative to the screen). Don't put instructions or indicators where the user's hand or arm will obscure them when trying to use the control they relate to (eg typically put them above rather than below the control).
Depending on the environment, make sure your touch screen is suitably proofed against dust, damp, grease etc and make sure it's easy to clean without damaging it. You wouldn't believe the slime that can quickly accumulate on a touch screen in an industrial or public setting.
The other obvious one is that there's no equivalent of pointer 'hover'. Not that that affects many apps though.
If you decide to put in analog controls (scrollbars, rotation widgets, etc) be sure to put in a digital control also. Some companies think that a touch screen means perfect control over something with your fingers. In real life, this translates to minutes of frustration trying to fix a number that's just a little off.
The most obvious thing is that everything on the GUI needs to be big enough for a fingertip to hit, which is sometimes bigger than you think.
As has been mentioned, there's really no way for a right-click action to happen. Also, double-clicking can be tricky with a fingertip on a touch screen.
The other major thing is that you'll want to create a on-screen keyboard that pops up for text entry and an on-screen numpad for number only fields.
I wrote my own set of controls for a POS application designed specifically to be touchscreen friendly.
Remember to allow enough real estate for stubby fingers and talons. In our application the users can have these manicures that necessitate them to use the pad of their finger instead of the tip. This means that you need to allow more space for activation areas than you would normally consider in any other type of application.
I would also recommend that you accommodate yourself as a programmer from a testing standpoint and from the point of view that things change and there may need to be a keyboard/mouse attached to a non-touch workstation. I cannot tell you how many times I went to touch my flat panel LCD expecting something to happen, before remembering that I had to use the mouse.
Make sure to read your basic UI principles like Fitz law (The time to acquire a target is a function of the distance to and size of the target).
Also consider whether or not the device is stationary or not when it is in use (e.g., like a palmpilot or iphone), research shows that you must accomodate that into your design.
The larger gui elements is the major thing. But it applies to all elements, scroll bars, tabs and even text fields.
The other major thing that I can think of, it's hard for the user to right click. So things that require a right click should be avoided, context menus are the only thing that comes to mind at the moment.
The other responses are pretty good, but are you totally sure that a touch screen would actually be easier to use? There are a lot of devices where a touch screen actually makes them much harder to use, not easier. The main problem is that you can't use the device when you're not looking at it. If users are going to be doing a lot of repetitive actions, a keyboard could be a lot more efficient.
Also, a touch screen might be a lot harder to use by someone with a disability, if you think there's even a small chance that could happen.
Even though this is quite old now, I found it to still be useful, as a starting point for design considerations.
http://www.sapdesignguild.org/resources/tsdesigngl/index.htm
If you've not already done so, have a look at some of the documentation available for developers on mobile platforms, eg Windows Mobile, iPhone.