I have a UIActionSheet which gives the user a few standard choices. The text on the buttons, however, does not cleverly scale down like a text field though when there's too much-- it just truncates with an ellipsis.
I need to say a little more in on of my action sheet buttons than there's room for. I don't see any way of changing the action sheet's behavior, unfortunately. Any thoughts on alternatives?
Thanks!
You could put some of the descriptive text in the UIActionSheet's title property, and then give just the verb or something concise in the button titles.
One alternative is: you might want to create a full-screen view that you show with presentModalViewController:animated:, where you have more space to show the text.
A third alternative is to create a UIView that animates up with UIButtons that you can customize, but doesn't fill the entire screen. I do that with some of my apps where the Settings are in a tab that slides up but doesn't need to cover the entire screen.
Related
I am building an iPhone app for a library and I want to give few options to the user to search books by. A user can search a book by title, author, topics, or date of publication.
What I want to know what's the best way to display these search options to the user? In terms of HTML, it would be easy - either use a drop down list or radio buttons. I tried using UIPickerView but honestly, that looks terribly ugly and destroys the aesthetics of the view of my app.
The other option I was thnking was using segmented control, but is it possible to have a vertical segment control in stead of horizontal one? The selection texts can be too long.
Any ideas?
If you want a vertical segmented control, you'll have to make it yourself. Create a textured image with dividers. I would export each section as a PNG separately. Then create a picture of each section with the "pressed down" gradient and export each segment as a separate PNG again.
I would then make a new class. If there is a specific number of objects in your segmented control or this is a one time thing, the class may not even be necessary. If not, then in the class constructor pass an array with the titles of the segments in your segmented control. For the first and last objects, use the pictures you made with rounded corners. For the objects in between, use the standard pictures. Then put the titles on top. When a segment is tapped (perhaps use hidden UIButtons), you can use a delegate method to tell the main search class which one was tapped, and then the class can replace the normal picture of that segment with the pressed down one.
Thanks for the options.
I ended up creating a simple table to show my choices.
User clicks on "search by", which opens up the table with options and then when you select any option, you return back to main view with the chosen search option.
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.
in my app i use a navigation controller and a tabBar for my views. The problem is that the titles that i have for the views are a little too long to fit.. they appear like in the photo below.
alt text http://img17.imageshack.us/img17/1524/picture2usx.png
could someone give any suggestions for resolving this problem? i tried subclassing UITabBarItem but i can't add a label as a subview, i can't change the font or size.. it looks ok when i have only 4 buttons but that is not ok because i need that more button. cutting down the names is not an option either, i don't think apple would like that.
thank you in advance.
As far as I can tell, there is no way to do what you want to do easily.
You could build some of the name string into your icon image. This will of course force you to internationalize your icon images, and you will also end up with the blue coloring in some of your text.
You could have no titles at all, and overlay your font-scaled title by drawing on the containing view. Note that when there is no title in the tab bar item, the following page will also have no title in the title bar.
Better by far, if you can do it, is to shorten the names. I know this is tough in German, but surely there must be alternatives.
I hope that Apple improves this in 4.0, but as those fonts are already fairly small, I sort of doubt it.
I want to introduce a custom pencil accessory image in a tabel cell and in the standard accessory righthand UITableViewCell position. The pencil image will be used to indicate that the text in the table cell can be edited via a popup modal full screen view.
Will Apple penalize this innovation during the app review process?
My justification is that the standard disclosure indicators do not convey the right meaning. According to the Apple HIG doc the ">" disclosure should present another more detailed list view and the the blue "+" disclosure button should reveal extra details about the selected table row.
I feel that opening a text edit view falls between the ">" and "+" usage, hence my pencil image idea.
Edit: Just to complete the picture, the table view has two fat rows. The upper row poses a multiline question and the lower row shows a text answer.
I don't think that Apple would penalize you for creating a custom button/icon. This is not something to concern. The problem here is to make you user understand what is the function of you custom icon, since they are used with the standard iPhone UI.
I my opinion for the functionality that you want to put on your icon, it would be better if you use the custom UI for editing table cell, that is presented on this image that I could find Googling (http://adeem.me/blog/wp-content/uploads/2009/UITableView/AddDeleteReorderUITableView/Picture%202.png).
So, people are used to edit the content of table cells by using the edit button and after pick the current cell...than you can show the modal view, so the user can edit the content.
To have a better picture, compare your table cell with, for example, the Clock app.
Try to avoid custom controls as much as you can. if something exists on the standard UI, go for it it is easy for people to look and understand.
Imagine that in your browser the load icon, instead of this circular arrow, it was changed by "L" in the latest update, would be something tricky to us to understand a non-standard symbol.
Think about it and chose the most appropriated approach for your purpose.
Cheers,
VFN
Does anyone have any examples or resources where i might find information on scrolling text which is too long to display in a button control? I'm thinking something along these lines.
Display as much text will fit within the current rect with a '...' at the end to signify overflow.
Pause for say 1 second then slowly scroll the text to the right edge displaying the right part of the string.
Display as much text will fit within the current rect with a '...' at the beginning to signify overflow.
Start the whole thing over in reverse.
Is there an easy way to do this using the "core" or built in "animation" frameworks on a certain mobile device?
[edit]
Iwanted to add some more details as i think people are more focused on wether or not what i'm trying to accomplish is appropriate. The button is for the answers on a trivia game. It does not perform any speciffic UI function but is for displaying the answer. Apple themselves is doing this in their iQuiz trivia game on the iPod Nano and i think its a pretty elegant solution to answers that are longer than the width of my button.
In case its the '...' that is the difficult part of this. Lets say i removed this requirement. Could i have the label for the button be full sized but clipped to the client rect of the button and use some animation methods to scroll it within the clipping rect? This would give me almost the same effect minus the ellipses.
Here's an idea: instead of ellipses (...), use a gradient on each side, so the extra text fades away into the background color. Then you could do this with three CALayers: one for the text and two for fade effect.
The fade masks would just be rectangles with a gradient that goes from transparent to the background color. They should be positioned above the text layer. The text would be drawn on the text layer, and then you just animate it sliding back and forth in the manner you describe. You can create a CGPath object describing the path and add it to a CAKeyframeAnimation object which you add to the text layer.
As for whether you think this is "easy" depends on how well you know Core Animation, but I think once you learn the API you'll find this isn't too bad and would be worth the trouble.
Without wishing to be obtuse, maybe you should rethink your problem. A button should have a clear and predictable function. It's not a place to store and display text. Perhaps you could have a description show on screen with a nice standard button below?
Update with source code example:
Here is some ready to use source code example (actually a full zipped Xcode project with image and nib files and some source code), not for the iPhone, not using Core Animation, just using a couple of simple NSImages and a NSImageView. It is just a cheap hack, it does not implement the full functionality you requested (sorry, but I don't feel like writing your source code for you :-P), horrible code layout (hey, I just hacked this together within a couple of minutes, so you can't expect any better ;-)) and it's just a demonstration how this can be done. It can be done with Core Animation, too, but this approach is simpler. Composing the button animation into a NSImageView is not as nice as subclassing a NSView and directly paint to its context, but it's much simpler (I just wanted to hack together the simplest solution possible). It will also not scroll back once it scrolled all the way to the right. Therefor you just need another method to scroll back and start another NSTimer that fires 2 seconds after you drew the dots to the left.
Just open the project in Xcode and hit run, that's all there is to do. Then have a look at the source code. It's really not that complicated (however, you may have to reformat it first, the layout sucks).
Update because of comment to my answer:
If you don't use Apple UI elements at all, I fail to see the problem. In that case your button is not even a button, it's just a clickable View (NSView if you use Cocoa). You can just sub-class NSView as MyAnswerView and overwrite the paint method to paint into the view whatever you wish. Multiline text, scrolling text, 3D text animated, it's completely up to your imagination.
Here's an example, showing how someone subclassed NSView to create a complete custom control that does not exist by default. The control looks like this:
See the funny thing in the upper left corner? That is a control. Here's how it works:
I hate to say that, as it is no answer to your question, but "Don't do that!". Apple has guidelines how to implement a user interface. While you are free to ignore them, Apple users are used to have UIs following these guidelines and not following them will create applications that Apple users find ugly and little appealing.
Here are Apple's Human Interface Guidelines
Let me quote from there
Push Button Contents and Labeling
A push button always contains text, it
does not contain an image. If you need
to display an icon or other image on a
button, use instead a bevel button,
described in “Bevel Buttons.”
The label on a push button should be a
verb or verb phrase that describes the
action it performs—Save, Close, Print,
Delete, Change Password, and so on. If
a push button acts on a single
setting, label the button as
specifically as possible; “Choose
Picture…,” for example, is more
helpful than “Choose…” Because buttons
initiate an immediate action, it
shouldn’t be necessary to use “now”
(Scan Now, for example) in the label.
Push button labels should have
title-style capitalization, as
described in “Capitalization of
Interface Element Labels and Text.” If
the push button immediately opens
another window, dialog, or application
to perform its action, you can use an
ellipsis in the label. For example,
Mail preferences displays a push
button that includes an ellipsis
because it opens .Mac system
preferences, as shown in Figure 15-8.
Buttons should contain a single verb or a verb phrase, not answers to trivia game! If you have between 2 and 5 answers, you should use Radio Buttons to have the user select the answer and an OK button to have the user accept the answer. For more than 5 answers, you should consider a Pop-up Selector instead according to guidelines, though I guess that would be rather ugly in this case.
You could consider using a table with just one column, one row per answer and each cell being multiline if the answer is very long and needs to break. So the user selects a table row by clicking on it, which highlights the table cell and then clicks on an OK button to finish. Alternatively, you can directly continue, as soon as the user selects any table cell (but that way you take the user any chance to correct an accidental click). On the other hand, tables with multiline cells are rather rare on MacOS X. The iPhone uses some, but usually with very little text (at most two lines).
Pretty sure you can't do that using the standard API, certainly not with UILineBreakMode. In addition, the style guide says that an ellipsis indicates that the button when pressed will ask you for more information -for example Open File... will ask for the name of a file. Your proposed use of ellipsis violates this guideline.
You'd need some custom logic to implement the behaviour you describe, but I don't think it's the way to go anyway.
This is not a very good UI practice, but if you still want to do it, your best bet is to do so via a clickable div styled to look like a button.
Set the width of the div to an explicit value, and its overflow to hidden, then use a script executing on an interval to adjust the scrollLeft property of this div.