I am working on a site that will have very high international distribution and need to understand the maximum width of a like button in any of the available languages.
So far, the biggest Like button I can find is in Russian - http://cl.ly/Jmeb.
Is there a full specification list containing the size of the like button for each available language?
Well, the most robust way to design your site is to not impose tight limits on the size of the Like button. The Facebook Developers topic Internationalization says,
Avoid Layouts Relying on Precise Sizing
Try not to use layouts that depend on the precise onscreen sizes of pieces of text in the original language. For any piece of text, in some languages it is likely to be shorter and in some it will be longer (sometimes significantly so in either direction.) If you have sized your user interface elements such that your text just barely fits, your application will probably not work well in a language with longer words.
Similarly, the Facebook Developers topic Like Button says,
You may need to adjust the width of the Like button to accommodate different languages.
You found a Like button in Russian that is 110 pixels wide. Can your layout work with a button that is 1.5 times as wide? 2 times as wide? 5 times as wide? Then you are probably safe.
But the browser is retrieving they Like button image from Facebook when it displays your page, right? So even if we can give you a full list of the size of the Like button for each available language today, tomorrow Facebook could add another language which has a longer Like button.
That said, Facebook does give code for getting the Like button in any language you choose (see FAQ: How do I display the Like button in different languages?):
src="http://www.facebook.com/plugins/like.php?locale=fr_FR&...
Facebook also publishes an XML file listing the locales that Facebook supports. With a bit of Grep search/replace, we can generate an HTML page which displays Like buttons in all 76 locales listed today. Looking at the width of those buttons, we see that Irish localisation of the Like button is the widest at the moment, with 127 pixels. (On my system, the Like button in Malayalam comes up a bit wider at 169 pixels, but that's because I don't have a Malayalam font installed, so the button displays with missing-glyph boxes.)
So, it looks like the maximum width of a Like button in the languages supported at the moment 169 pixels wide. But, coding to this width is not what Facebook, or good internationalisation design, recommends. Instead, make your layout flexible, and able to cope with wider Like buttons in some locales.
Related
I'm having an issue with Outlook and when Windows Display (Control Panel > All Control Panel Items > Display) is set to Medium - 125% (or larger)
The text in the newsletter appears bigger and is creating issues with spacing. Although most of the issues with this can be resolved, I would like to know if there is a way to force Outlook to respect the pixel sizing as defined in the html email.
An example code block is something on these lines
...
<td width="460" valign="baseline">
<p style="font-size:16px;margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;" >Hello </p>
</td>
...
The text inside the <p> tag is 16px on a machine that has Windows Display 100% but is larger when Windows Display 125% (interestingly, the browser still respects the 16px and does not increase the font size like Outlook)
I don't think you're taking the right approach to this problem. Please look at it another way.
The user said "I want my text to be bigger". They probably said that because they have a very high res display or they have visual difficulties. It's their preference, if not their need, to have bigger text.
You're saying "how do I override the user's preference for my cosmetic convenience?".
Don't do that. Fix your layout's design so it adapts better to varying text sizes.
Reduce your image use and/or place your images so that they can handle being pushed around by the text. Consdier using scalable units like em or percentage font sizes to be more friendly toward people with visual difficulties or very-high-res displays.
Background:
The reason Windows scales fonts (and pixels) like this is because software developers for the platform have been consistently ignoring the font sizes the user sets in Explorer and the theme. Apps often force the use of their own fonts with specific pixel sizing instead of using the system fonts and sizes.
This has led to lots of apps that're unusable for people with visual difficulties, on media PCs, etc.
Microsoft wanted to give users a way to override these badly behaved programs, so they gave users a way to scale the pixel sizes provided by applications by a fixed percentage. Essentially they redefined a font "px" as an abstract unit that can be scaled.
Your HTML email is trying to be one of those badly behaved programs.
In my iPhone app, my navigation bar titles were often too long for the page, causing them to truncate (I usually have a button either side of the title, so space is limited). I therefore created my own title labels with a hard-coded font size so the text would shrink accordingly. However, I now realise that this wont neccesarily look right when other languages are chosen.
What is the normal practice for this? Do people just accept a truncated title, or reduce the font size accordingly (for English), or enforce a very short title that will be short enough in all languages?
I don't think there's a magic solution here. You just need to pick shorter titles or accept the truncation. You can always put the full text in the display rather than in the title bar if necessary.
Based on feedback from some users, I wouldn't go down the route of using smaller text. (I'm basing this on a toolbar at the bottom of the screen rather than the title bar, but the same principle applies.)
I chose one title that is short enough for every language and display it regardless of what the view controller shows.
Apple shows as a title what the view controller shows: in the iPod app, for instance, when you select a playlist, the whole name is displayed. If it is too long, it gets truncated.
So I think it is ok to show a truncated title. You should not however make the text smaller as it will get too hard to read.
Thought it would be relevant to contribute to this discussion with a great solutoin that I came across in one of the apps I've been using.
https://itunes.apple.com/in/app/bookmyshow-movie-event-play/id405894842?mt=8
These guys animate the title left and right within the titleview's bounds, if the title text is too long. Looks neat and elegant without truncation, smaller text or other hassles.
I find some iphone book apps have such feature:
One screen one page of text without scrolling. The text can just fit into the whole screen with linebreaks and indentations.
I'm curious of how to implement this. How could I decide the length of text that just fit into the screen. And also, given the whole text, I can calculate out the number of pages.
If this is not possible to be done on iPhone(runtime?), then is it possible to process the text before storing it in app? I mean I calculate how many pages I need(how to split the raw text), probably how many lines per page.
I think this is what you are looking for
iPhone SDK: How do you measure the width and height of a string using Quartz?
The accepted answer gives methods you can call on NSString to calculate sizes
What I did for TouchTomes' books was have two iPhone apps. One was the reader that showed up on the App Store. The other was a renderer that calculated what could fit on each page, that only needed to be run in the simulator to create a book DB that the reader could use.
It would throw up a bunch of text, say 100 words, and see if that overflowed or underflowed. If it underflowed, more text was added (say 20 words) and it would binary search until it found exactly how much text would fit. Then it stored in a SQLite DB a row saying "page 12 shows words 100-228" for example. The app would go through this for each font. Another table held all the words in individual rows (!). An optimization step would chop that table down, combining words that always appeared on the same page no matter what font.
I used a Webkit display so the book could include HTML formatting. Now that really complicated the page breakup (e.g. had to keep italics going from page to page) but it let me include some fancier formatting in the text.
Then the reader app had very little to do to display pages; from the page id look up what range of words go on that page, then throw that text up into a webkit view. The user could jump between pages all over the book very quickly, all the hard CPU work had already been done by the rendering app.
We are trying to write a training manual application for the iPhone. On the top half of the screen is a diagram of a car engine, on the bottom half is some text. At the user repeatedly hits a "next" button, we highlight different parts of the engine, and in concert we highlight different parts of the descriptive text below.
We basically want "living text" in the text half, with the illustration following along on top to where the reader is in the text. What we'd like from the text is 1. user can scroll it using their thumb so possibly a UIScrollView 2. the software can explicitly drive a scroll to any part of the text (when they hit the "next" button). 3. the words in the text are interspersed with hotlinks e.g. "this is the camshaft... this is the piston..." and the user should be able to click on any of the keywords like camshaft, piston, and have the diagram highlight that. (The problem is not highlighting the diagram, its capturing the click). The text would have 300~400 buttons/links/keywords and about 600 words of text.
Since this is fairly similar to using a web browser, we tried using Apple's version of webkit using a UIWebView and handleOpenURL to register a service back to the app itself. But Webkit for internal links a popup comes up asking permission to access that link. Every single the user wants to go to a link (in our case just an internal event that we'd intercept so that we can highlight e.g. the camshaft). Tried to intercept the event from the HTML view, but that didn't work.
It seems like the best we can do is to abandon scrolling text, and make the text part more like flash cards or a power point presentation, breaking the text into custom UIViewCells with buttons inside a UIScrollView. However, this would impose an annoying constraint on the author that they would have to write everything to fit in the UIViewCells, sort of chunky.
Any ideas would be appreciated.
This is definitely something you can use a UIWebView for. Don't use handleOpenURL, rather, set your viewController as the webview's delegate, and override -webView:shouldStartLoadWithRequest:navigationType:. When this gets called, check the request, and pull out your link data from there.
It would probably be easier to implement that completely in JavaScript in the document you load in a UIWebView. You would have to use JavaScript (i.e. [UIWebView stringbyevaluatingjavascriptfromstring:]) anyway to achieve things like scrolling to a certain position.
Regular HTML select boxes (such as, e.g. found here), while being "chosen" are presented by the iPhone on a native widget that seems to totally ignore regular html font sizes and whatnot. It does some ellipsing when it goes too long, but the font is way too big for a list I want to present -- even on landscape, only about 35 characters can fit.
Is there any way to tell the iPhone to use a smaller font there?
This is not possible. Use radio buttons instead.
Also, you can create custom select boxes. If created the good way, it works great. One small misstep and the UI is a disaster.