NTQZ is upgraded on App Store worldwide!
Filed under NTQZ
Life seems to be a choice between two wrong answers.
- Sharyn McCrumb
 |
Do you know what am I going to talk about? You are wrong! Read on…!
What? You don’t know? Can’t grasp the initial quote? Read on…!
(Choice between two wrong answers can’t be worse than this 
)
Tomorrow’s world would require your kids not only to be capable to earn their bread, but also to sustain and grow themselves in competition.
They not only need to be extra-capable, extra-efficient, but also super-knowledgeable and ingeniously creative.
They need to learn things different way than you did.
It’s great to buy amazing cloths for your kids.
But as time flies, you will realize it’s also important for them to learn what’s worth wearing.
It’s great to make them great recipes when they come back home.
But as they grow, it’s also important to make them realize what should be eaten at what times. And off course, what should be avoided.
Parental discretion can greatly help up to certain age, but that’s never guaranteed to sustain. It cripples their transition to maturity.
Blast of information and networking ensures that your kids ought to be lot more independent than you once thought. And they need to self-dependent far earlier than you yourself became.
Like food, fashion and career, and more than all of them, learning requires discretion.
It’s true that everything can be taught.
But what’s worth learning can’t be!
Your kids not only need to know and memorize the facts.
They also need extra-super judgement about what’s worth their attention.
They need to observe, keenly observe, and grasp useful things fast.
They need to distract from trash even faster.
They must know what to avoid, and how quickly.
They not only need to know what’s correct answer to a given question, out of choices given to them.
They also need to know why it’s single most correct answer.
They also need to know why all other answers are wrong – to make that single answer the most correct.
They also need to know what’s worse than being right, and what’s worst – the wrongest!
In a life when you simply can’t resist what’s worst, you can at least choose how to react to it.
(Now you know why I quoted Sharyn McCrumb in the beginning…)
Being able to choose a wrong answer is a special ability that everyone possesses. But it must be cultivated. Your kids must decide whether to hate or laugh at the wrongest. And if they are trained at it, they can easily do so.
Not convinced?
The real magnetic test of an iron rod A is not whether it can attract another iron rod B. Come on, even B could be a magnet.
The real test would be, whether A repels B or not. Only a magnet can repel another magnet, not an iron rod.
Still confused?
Read this.
NTQZ (aNTiQuiZ) an educational product aimed at raising your child’s wisdom bar. It incites your child with questions that surround amazing facts that just wait to be digested. The carefully chosen trivia questions simply open the door to so much content that your kids are hungrier after answering them. They just can’t stop reading encyclopedia articles surrounding it.
What’s more, they are encouraged to be extremely creative (read wrong) about each of them, and are rewarded for them. The experience enhances their analytical strength and creativity. Leisure of being wrong is a fountainhead of creativity.
As a result, after taking NTQZ, your kids are not only knowledgeable, but also are wiser, wittier and funny.
With knowledge, they can’t lose a competition – that’s better than anything.
With wisdom, even if they lose, they don’t lose in life.
And what’s better than that? Huh?
Image courtesy of Stuart Miles at FreeDigitalPhotos.net
Filed under NTQZ
Three seventh graders – Peter, Jake and George – are poking fun at each others’ general knowledge in a cafe.
Peter: Let’s see which one of us can win ‘Who wants to be a millionaire?’
Jake: You two (chewing his doughnut)
George: Give up?
Jake: I said – you two fight for the second spot.
Peter(smirk): Ah, let me test you first.
George (grabbing doughnut from Jake’s hand): Yeah yeah, you first.
Jake: uh oh…
George: Lemme help myself with that…Peter, screw him.
Peter: Tell me, which city is the capital of United States?
Jake: Give me the options.
Peter: I knew, you suck.
George (taking a heavy bite off Jake’s doughnut): why not….they are: New York city, Washington DC, Canberra, and, and, and Bonn – from West Germany, if you don’t know.
Jake: Let me take a guess…
Peter (grabbing the last bite off Jake’s doughnut): While we finish up your breakfast.
Jake: That’s Bonn.
Now – imagine for a moment what Peter and George are thinking: that, if there is a word more derogatory than ‘moron’, then Jake deserves it (there are many, can see you murmuring!). Jake didn’t even think of the Big Apple. Jake fails their GK test. The probability of Jake winning ‘Who wants to be a millionaire’ is negative infinity.
The fact is, our kids’ answers aren’t less disturbing than Jake’s answer.
And, like any careless teacher or a busy parent, we choose to let it pass. Or maybe, call them names, like Peter and George are going to.
Now let’s see how this conversation meets its end.
George (Laughing out loud, everyone in the cafe is looking at the threesome): Knew it.
Peter: That’s not funny, George.
George: Then what’s funny? Do you want to ask him who’s miss America 3012?
Peter: Let’s hear out his reason…that must be funny.
Jake: Well, the funny thing was – you asked a would-be billionaire a very very silly question.
Peter: Yeah, that’s right, and you answered it with utmost sincerity…now tell us why you think its Bonn.
Jake: Washington DC is a no brainer – I mean, why? And since New York was a US capital during 1785-1790, no point in guessing that either.
George: And why not Canberra…
Jake: Well, I thought that, but then Australia is still governed by the Queen of England who also ruled US once.
Peter: And what brings Bonn in…
Jake: West Germany was dominated by US, so there is not a slightest chance a US capital would be named after that of West Germany. If it was, in the past, US would rename Germany’s Bonn to something else.
George: But why you chose to be funny when we were testing you?
Jake: Well – I didn’t think the question was worthy of that…
George: Oh…you just chewed up fun of the moment.
Jake: Like you chewed my doughnut.
Your child could be like this:
Or better be one of these (hereditary, maybe?!):
But maybe he is best as this:
The conclusion?
Not every child that gives funny answers is a moron.
World mocks at the genius, but the genius mocks back at it. (like the bubble boy? We are flattered!)
Creativity and inventions arise from fuzzy logic and funny methods.
Yes, there must be another way this could have ended. That Jake was indeed a moron, and didn’t know what US capital was. Playing along, he said Bonn. And when he told Peter and George, they must have had a better laugh. Which would have made Jake wonder about it – about why Bonn was not only a wrong answer, but also the most improbable, and somewhat funny, and that’s why it made them laugh hard. Yes, he maybe humiliated a bit, but the end objective – to make him ask ‘why’ will be served.
All questions in NTQZ follow the same pattern: Punish the right answer (negative points), and reward the wrongest one (positive points). That’s incentive for being wrong, minus humiliation. Created and designed by Nirav Bhatt, it is available worldwide as Freemium.
Leisure of being wrong is goldmine for creativity, and NTQZ ensures this leisure to every player.
NTQZ is a novel concept in General Knowledge education. It is prolific wit, wrapped in fun. It unlocks your kid’s infinite potential to become a witty and wise genius.
If you think your Jake is a real moron, contextual wikipedia tells him that Washington DC is the right answer.
It’s funny tips, like Peter and George, will show him how other cities are improbable capitals, and why Bonn is the funniest one.
Next time, he knows how he can be witty.
And yes, he will just chew up the fun out of kids who grab his doughnut.
Filed under NTQZ
In this new category of posts, we will include tiny tips and tricks that makes you pull your hair in the dark of the night!
Here is first one.
Very often, you are challenged with weird UI requirements – putting an interactive control under Navigation bar is just one of those headaches. It is very easy to forget the basics when things get mixed up. Here is step by step:
- (void) addPassWord
{
CGRect textFieldFrame = CGRectMake(20.0f, 100.0f, 280.0f, 31.0f);
UITextField *textField = [[UITextField alloc] initWithFrame:textFieldFrame];
textField.placeholder = @"Enter Text!";
textField.backgroundColor = [UIColor whiteColor];
textField.textColor = [UIColor blackColor];
textField.borderStyle = UITextBorderStyleRoundedRect;
textField.clearButtonMode = UITextFieldViewModeWhileEditing;
textField.returnKeyType = UIReturnKeyDone;
textField.delegate = self; // ADD THIS LINE
self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithCustomView:textField];
}
@interface TabAppMasterViewController : UITableViewController <UITextFieldDelegate>
- (void)textFieldDidBeginEditing:(UITextField *)textField
{
NSLog(@"begin!");
}
- (void)textFieldDidEndEditing:(UITextField *)textField
{
NSLog(@"end!");
}
- (BOOL)textFieldShouldReturn:(UITextField *)textField
{
[textField resignFirstResponder];
return YES;
}
PS: Hate patchwork? Here is entire package,
Filed under iTipsNTricks
In our previous post we characterized content for localization. Our current post is aimed at emphasize the approach towards the first category of localized content: static content.
One thing to clear before proceeding: Apple documentation, or for that matter, any application API provider specify no distinction made between static content and dynamic content as far as localization is concerned. It’s app developers’ responsibility to categorize the content he owns, where to fit it into his data model, and how to bring it to the end user. It’s just an approach to look at the data we deal with, and based on the day-to-day problems that developers face, API providers bestows us with nuts and bolts that we can work with to develop our great apps in affordable and extendible way.
All disclaimer in place, now lets just rush to localize static elements of our great international app.
Let’s follow our old example of online bookstore database. We had 3 items to present:
Book title – Localizable – Dynamic (remember we are dealing with translated books)
Book Author – non Localizable
Publisher – non Localizable
Now let’s imagine our great bookstore app has having at least 2 screens:
Screen 1: Book List (localized list of books – book titles will appear in respective language)
Screen 2: Book details (localized details of a selected book from screen 1 – book details like title will appear in respective language while publisher and author names will remain as it is)
Have a look at how both look: Screen 1 shows French translated versions of 3 of the most popular novels all time. When any one of them is tapped, Screen 2 follows to show us Book title, Publisher and Author details. Fair and Simple master-detail app.
Now, where is the place which is perfect candidate for statically localizeable content?
Let me give you a hint. It’s in all-pink Screen 2.
Found it? Yes? Good, you seem to have followed my earlier post quite religiously.
No? Well, have a thorough look at screen 2 above, see the labels in brown color on the left-hand side.
On screen 2, the entries ‘titre’ (Title), éditeur (Publisher) and auteur (Author) are the statically localized strings. As discussed in our previous post, entity titles such as this are perfect candidate for static localization. They appear in apps, not on per item basis, but per entity basis. Since we had 3 entities – book title, publisher and author – we got 3 localized (french) strings to present them on our detail view (Screen 2).
Now, quick work. Those of you who came here for quick look into the code snippet, Ctrl + C, and sneak out, here comes your part:
1) There is a file that stores statically localized strings for each language. This file is called InfoPlist.strings. For english app (default locale), it resides under <Project Root>\en.lproj\ folder. If you are also offering french version fo you app, one more copy of InfoPlist.strings would reside under <Project Root>\fr.lproj\ folder.
2) The file for French locale looks like:
InfoPlist.strings
3) Here is how you access localized string values from this file:
NSString *bookTitle = NSLocalizedString(@"Title", @"Book Title Key");
For french locale app, the above code will fetch ‘titre’ string from <Project Root>\fr.lproj\InfoPlist.strings file and dump it (well, “copy”, if you say so) into bookTitle. bookTitle can later be used to display in the UI in the topmost left label. Other strings for publisher and author are pulled up likewise.
Pretty simple, right? All you need is key-value pairs ready for all elements that you identify as entities. Implementing localization is never complex; identifying your data model and entities really is. Work on that part thoroughly, and you have won the localization war.
In our next and final tutorial in series, we will deal with localization for dynamic content.
Till then, keep translating! (quite huge chunk of that is required for that part, you gotta believe me here.)
Filed under Localization
Localization is an edge every top app/game programmer wishes to give to their creation. By localizing your app, you can multiply your game audience manifold – with minimal effort. The reason to localize is to tap markets wherein users simply do not buy English version of the apps. And such markets are not in minority.
Having stated its importance, top game producers misses or avoids localizing – either due to hurry to ‘get it out first’, or simply due to lack of knowledge. Here, we will describe concise and clear steps to localizing, and thus globalizing your app.
This tutorial is the first part in the localization series. The forthcoming parts would describe in detail what are the best and most concise ways to localize content.
There are 2 parts in any app UI: labels, instructions etc that forms static part. Data – which is dynamic part.
The first part deals with elements that remain same with entire app navigation. Say you have a multi level game. Then, when you display ‘Level 1′ at the beginning – the text ‘Level’ forms static part. This is a perfect candidate for localization, because your users in Poland or Japan would like to see their localized word for ‘Level’ there. You do encounter levels quite often, but all you need to localize is single word ‘Level’ into various languages. This is the static part.
The second part deals with elements that are huge in quantity. The level number X in string ‘Level X’ falls into this part. If you have a game with 50 levels, and you want to provide non-English users the feature to see those level numbers in their own language, you must provide 50 numerics in each language. And you must tell your iPhone app to display that language specific X depending the user’s language. Such items are what forms the dynamic part of localizable content.
Looking at it more closely, the dynamic part deals with your business logic – you must ask yourself why your app exists – what data it provides to users. Say you have an app to display simple list of books (also translated into local languages), authors and their publishers, these are the items that fall under dynamic content category:
i) Book names (a book B would have 1 entry for English version, 1 entry for its Polish translated version, 1 more entry for its Japanese translated version, and so on) .
ii) Publishers names (A book B maybe sold by publisher P1 in US, publisher P2 in Japan, and so on)
iii) Authors names
If you see, you can quickly tell that items i) and ii) falls under localizable content. Author name wouldn’t change – if you want to put translators’ names, that’s a separate entity – but again, it wouldn’t be translated content per language, just a new entity of data.
So in esssence, the number of dynamically localized strings would depend on the extent of data you are dealing with. If your app aims to display 1 million book titles into English, Polish and Japanese, you would need 3 million localized strings just for book titles! Same holds true for Publishers data.
The static category, on the other hand, would be UI centric: It often depends on the type of things you are displaying. In the same book-publisher-author example, where you display Book title, you would like to include a label called ‘Book Title’ in English, Polish and Japanese. This is not per book, but per entity. In our example app, the number of entities is three (book title, publisher, author) – so we would need total 3 strings that need to be localized. The total number of localized strings would be 3*Number of languages you want to localize into.
Localized app is a great tool to sell your app – its a way to multiply your audiences without actually multiplying your marketing effort and costs. Today, we distinguished ‘what to localize’ items. In our next tutorial, , we would dissect how to localize each of this part.
Till then, keep translating!
Filed under Localization, Uncategorized
iPhonegamezone is to iPhone dev maniacs what a bar is to liquor hobyists! [iPhone dev maniacs - liquor hobbyists - oops, did I just mess up ? Well, I am not drunk...]
That was the whole idea. A little twist turns things upside down – and in a funny way!
Follow the traditions, leverage all that’s tried and tested, and then, give a slight, subtle twist to the shapes and structures – that’s the theme of this blog.
The manifesto?
iPhonegamezone will attempt to:
1) Help anyone grapple with all things related to XCode, Cocoa touch, and iPhone gaming in general. Will usually make things smoother so everyone doesn’t have to reinvent the wheel. Just giving back to the gaming community!
2) Gather tools and techniques that are great for beginners as well as proficient iPhone gaming enthusiasts.
3) Show-off some of the creative stuff that’s being created under the umbrella of iPhonegamezone.wordpress.com.
Lets see how do we get along, and how many hi-fives we get from our fellowmen!
Sign off for now…
Filed under All Things Formal
