I'd like to draw attention temporarily (±1 sec) to a value in a UILabel when a user changes something elsewhere on the screen. I know Apple is pretty particular about what and how people add "pizazz" to their apps...and for the most part I think it's for good reasons but in my case I feel my UI would really benefit from a subtle animated effect of some kind.
So I'm asking the UI police if there is an acceptable way to bring "tasteful" attention to a UILabel?
Currently I'm animating a color change to a lighter shade and back again but it's not quite "strong" enough.
Maybe some kind of a glow effect? (prolly a huge HIG no-no if there is even framework support for it?!?)
Edit - Example:
There's a good example of what I'm thinking might work that is right in front of our eyes. When you type the the 2nd half of a paren or "]" or "}" in XCode other, corresponding half "(", "[" or "{", is briefly highlighted. How is that accomplished? Is that just a simple view behind the character that fades in and out?
What you are describing probably won't be a problem with Apple. The main thing they seem to dislike is when you take an Apple standard usage and use it to mean something different.
So for example, if you added a symbol like the little x-circle that you find inside UITextField boxes, and used it in a UITableViewCell to mean "Search" -- Apple won't like that.
Good idea. Well, you could use an image with alpha that fakes the glow. Just fade it in and out quickly.
My english is not so good, but are you concerned about apple rejecting your application just because of an animated lable? don't worry.
Animated color change is probably the best you're gonna get if there's no built in UI support for it. Apple won't reject your app for this, but it will bother some purists.
You could consider some of the more traditional messaging frameworks to draw attention to the concept you want to highlight for the user.
In my apps TafelTrainer and TafelTrainer+ i blinked the UILabel for a short time, and they both came in without problems.
Related
If you implement UITextInput on your custom view and - say - use CoreText to render the text you get to a point where you can draw your own cursor and selection/marking and have that fully working with the hardware keyboard. If you switch to Japanese input then you see the marking, but there's something curious: if you long press into the marking you get the rectangular system loupe and selection handling without having to deal with the touches yourself.
What I don't get why we would have to implement our own touch handling for the selection, draw our own loupes etc. It's working for marking! So what do I have to do to get the standard gesture recognizers added to my custom view as well?
the one sample on the dev site only has a comment about that user selection would be outside the scope of the sample. Which would indicate that indeed you have to do it yourself.
I don't think that it is in Apple's interest that all developers doing their own Rich Text editor class keep doing their own selection handling code, let alone custom drawing of the round and rectangular loupes?! Granted you can try to reverse engineer it such that it comes really close, but that might give users a strange feeling if the selection mechanics differ ever so slightly.
I found that developers are split in two groups:
1) rapes UIWebView with extensive JavaScript code to make it into an editor
2) painstakingly implements the selection mechanics and loupe drawing themselves
So what is the solution here? Keep submitting Radars until Apple adds this missing piece? Or is this actually already existing (as claimed by the aforementioned engineer I met) and we are just too stupid to find how to make use of it, instead resorting to doing everything (but marked text) manually?
Even the smart guys at Omnifocus seem to think that the manual approach is the only one working. This makes me sad, you get such a great protocol, but if you implement it you find it severely crippled. Maybe even intentionally?
Unfortunately the answer to my question is: YES. If you want to get selection mechanics on a cusrom view you have to program it yourself.
As of iOS 6 you can subclass UITextView and draw the text yourself. According to an Apple engineer this should provide the system selection for you.
Is pinch for font size changes in tableview ok re usability?
Seems a good idea from my perspective, but wondering would users find it ok, or does it break an iPhone best practice?
I read through the tableView human interface guidelines and didn't see anything explicit there. In the Direct Manipulation section it says:
people can use the pinch gestures to directly expand or contract an area of content
If the user is using a pinch and zoom to change all text in a tableview it doesn't really seem to me like it is really proper "direct manipulation." It seems like it is more of a global setting change with a generic gesture. I think the real decision would come down to why are you planning to offer this gesture to the user? Is there a common use case for your app that the user would want to adjust the font size often? Are they going to change it more than once per session?
I know it is nice to offer lots of features, but any extra features are just going to obfuscate the real features. It may confuse the user if they accidentally do a pinch and then the text size is changed and they don't make the connection.
Overral, I don't think it breaks and explicit rule, but I would be really careful about deciding to add this "feature." If there is a really good reason to do it, I would say go for it, otherwise, it probably isn't worth the risk of getting rejected from the store and/or possibly confusing the user.
I vote no if it's key to the functionality of your app. You're having to train people to do something that may not be intuitive for them to realize that's there. If you look that the Twitter official app, they do something similar to expand the content in that cell, but you could totally live without that capability if you didn't know it was there.
I am pretty new to iPhone development and currently working on an application which includes a view that performs a simple numerical calculation. In particular, the user enters 3 or 4 values into text fields and the view displays the result. Something along the lines of http://www.moneychimp.com/calculator/compound_interest_calculator.htm
What is the nicest way to achieve this? I am currently using simple UITextFields and a UILabel for the result but it doesn't look nice or "native-like". What UI object would be best to use?
Thank you!
It's entirely up to you. You're using the right classes for actual input- it comes down to how you choose to style those classes. I'd suggest looking at the documentation for UIView and CALayer (youView.layer, and include QuartzCore framework in your project).
A good start might be to choose a color scheme, a background for your app, and the look and feel you're shooting for- this will inform your styling. Try looking for apps that you think are elegant and attractive, and boil down what they do and what you like about them.
I'd say;
use a grouped table style (with the white tables with round corners on a blueish striped background)
embed settings values directly in the cell (aligned to the right) as much as possible
you can show a relevant keyboard (text, numbers) or picker view to let the user pick values, directly when they tap the cell. Use sliders and switches where relevant.
You may want to take a look at http://www.inappsettingskit.com/, we are currently investigating it for the same purpose and it seems to do the job
You can use either a UISlider or a UIPickerView if some of your values have limits.
You can use UISwitch for toggles.
You can also switch the default keyboard for your textfields to be numeric.
Other than that you seem to be on the right track.
Also, sometimes putting a view inside a scrollview makes things seem cooler even if its only one page. The auto bounce on scrollviews is kind of cool.
I want to implement a functionality similar to found in Pages app..i.e. text floating around images, image zooming etc.. I have been struggling with this part of my application but no success yet. Would be grateful if someone provides me with some pointers in this regard , like 'Which UIControl should I use?','Help in thinking logic' etc..
Thanx in advance.
Sounds like a fun app to develop.
Some Pointers:
Immediately off the bat, I would say look into creating your own Controls for the floating objects.
I would suggest tackling a smaller project, or maybe a few small to medium size projects. p
Try making a few apps with WinForms or WPF. Also look into XSL:FO.
Immediately off the bat, I would say look into creating your own Controls.
There was a WWDC session that talked about iOS text. I don't think it's violating NDA to say this is going to be a very hard project. No, make that very, very, very hard.
You will probably need to do all UI yourself, and use Core Text for rendering of the text. (But I believe you need to draw selection, etc.) And do the layout yourself.
Hope you all are fine and also in best of your moods.
I have a little problem kindly help me to get its solution.
my Problem is:
I am using vertical search in my application, using method sectionIndexTitlesForTableView() of tableview i get all Character listed from top to bottom at rightside.
But this letters have fixed color. i need to change this color. Since i newbie i don't know how to deal with it.
Please help to get solution.
Thanks, and sorry if you found me with wrong english.
There is no supported way to do this. Even if you had access to the index view (which you don't easily), it would not be possible because there is no NSAttributedString on iPhone, so you couldn't return color information.
The best way to achieve this is to turn off the tableview's index and generate your own from scratch, floating it over top of the tableview. But I would not recommend this approach for a new iPhone developer. It is best to spend some serious time learning to build UIs the way Apple intends you to. Once you understand Apple's UI and how it's implemented, then you can make informed decisions about whether you should break the UI rules.