How do you deal with formal / informal speech when building an application that must have all its phrases in one of those?
Most frameworks will let you pick the language for things such as form validation error messages, by setting it to something like 'en-GB' or 'fr-FR'.
But if you want to change from formal to informal or viceversa, you will have to edit the language files.
I know this isn't a big issue in english, but it is in other languages where you have to pick the correct word for say, the equivalent of 'You', depending on whether it is a formal or informal conversation. The same can happen with almost any word in the sentence, depending on the language.
Any thoughts?
Have you ever been told to build an application fully in formal / informal speech?
Does the user even care about this?
Informal vs Formal
The real problem with choosing the form is the fact that it really depends on who you speak to. It is probably OK to use informal messages to an English user, but it would be regarded as an offense if you use the same tone to for example Japanese user. It is the essence of Internationalization.
How to deal with it?
I suggest to pick one "tone" and consequently use it throughout an application. If it is informal (for example target users are teenagers), then be it. However, let Localization decide on how to translate these messages, for they should have the vast knowledge of target market.
If you need to have both formal and informal language in one application, for example depending on target user's age, you can think of implementing themes. Of course theme should not only customize messages but also the User Interface (styles, colors). Again, if you do, let L10n decide what is good for international market (some themes might not be applicable for that market).
Does user even care?
Some users do, some users don't. Depends. From my experience, Asian customers (especially Japanese and Chinese) tend to care a lot. Using informal speech or bright colors might seem as if you being rude to them.
Related
Trying to settle a debate with a client. I didnt localize the strings and images in the application and it didnt come up during the 3 week define and discover. They seem to think its a basic best practice and that it should have been done by default. I disagree, especially if there are no planned languages otw.
Seems like you would leave this for demand by users
So, Id like to ask the community to chime in on this and tell me if you by default have localized your iphone app or not?
I ask this to not only help me understand where I might have missed something but also to help others in the future as to what is considered "default" and "best practice"
This question is going to spark a lot of opinion. Because Apple makes it ridiculously easy on iOS to localize strings, I personally feel you should set all apps up for localization by default. Anywhere you find yourself defining a literal string, substitute it with NSLocalizedString(), until it becomes second nature. Then, if you decide you want to localize later, you don't have to hunt and peck all over the place. If you never localize, you lose nothing except a few keystrokes.
A true localization will probably have localized NIBs to (may have different sized buttons for different languages, for instance). Still, if you assign all strings that will appear in the NIB in code with NSLocalizedString(), rather than in Interface Builder, you'll likely save time in the long run.
The fact that the AppStore makes your app visible in so many countries greatly increases the demand to localize. Read this post by Wil Shipley about the money you could be making by reaching many markets.
First, you have to internationalize it, that is to write your code such that it is easy to add new languages. Default - and first - language is usually english (Apple makes things easier if you start with english and customers are more likely to buy an app in english only than in swahili only).
Second, you can localize it to languages that are important for customers of your app. spanish, chinese, french, farsi, ...
How could you possibly know what languages to use for localization without input from your client?
Assuming it was never discussed during requirements, it appears you are in the right here. If they wanted localized versions of their app, they should have requested it.
#greg has a very good point, in that it would have been beneficial to use localized strings from the very beginning, but setting up an app for localization isn't especially difficult. It's the actual translations that are difficult and expensive.
My small sample suggests that the vast majority of apps in the U.S. App store are not localized to any other language.
It may be technically easy, but can be editorially very difficult unless you have educated multi-lingual staff available (hiring multiple contractors to cross-review translations for grammatical correctness, doing multi-lingual app descriptions, app documentation, web site support pages, marketing materials, etc. in all the languages that might be expected for an app localized to those languages. Keeping all that editorially synchronized with every update/bug fix.)
It also appears that lot of apps add multi-lingual support only after International sales get to the level which can support the above initial and on-going costs.
i ask them going into it.
if i need a default answer, it is 'yes, prepare for localization'. it takes far less time to add it as you go, than the remove, rebuild, retest cycles.
Apparently Apple has changed some term in the agreement again.
From http://www.appleoutsider.com/2010/06/10/hello-lua/
section 3.3.2 is now
Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.
instead of the original
No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
I am more interested in embedding Lua, but other people have other embeddings they want to make.
I am wondering how you ask for permission, and what they mean by the terms "minor features" and "consistent" and how will Apple interpret this section? It seems to have enough loopholes to drive a real firetruck through.
(BTW this is a terribly important question for me an my product.)
Realistically, the ultimate interpretation of the developer agreement is up to Apple.
Since this is all new, it's not clear who to e-mail. You could start with the iTunes Connect people, but be prepared for a long wait to hear back. Alternatively, I've gotten some occasional quick help just by calling up the nice Apple people in Ireland.
Given the wording , if you want to embed Lua, you should be prepared to justify that you will be using Lua in a limited fashion to provide minor features or functionality.
Since you've stated this is a really important question, you might want to consider the risks inherent with pushing the envelope/being a pioneer. If there's an alternative way to get around all this, you should consider it. If there's no way around it, it might make more business sense for you to pursue another platform for now.
I've worked with several different types of "user-generated content" sites: wikis, a message board, blogs... These systems can differ greatly: a blog post editor allows more control over presentation than that for comments on the blog post, a wiki topic editor encourages wiki links over raw URLs, etc.
However, one key design decision is common to each: should I provide the user with a simplified markup language such as Wikitext, Markdown or BBCode, forcing users to learn that, or should I give them a WYSIWYG editor like CKEdit or TinyMCE and filter or transform the resulting HTML behind the scenes?
There was a time when I thought this was a simple matter of identifying my intended audience: tech-minded users get markup, non-technical get WYSIWYG. In practice, this hasn't worked out all that well, occasional users struggling with markup and the WYSIWYG editors providing at best a leaky abstraction for the underlying HTML.
So with my initial confidence throughly crushed, I come looking for advice:
What factors should I be taking into account when making this decision?
Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?
...Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?
I'm not looking to go back and tear apart what I've already done. For better or worse, these systems are working, their few users comfortable or at least competent by now. But it would be nice to have some better guidelines when putting together future designs.
One approach that seems to work fairly well is the use of Markdown as done here on SO. Stupid and/or lazy people (with apologies to all who are) can simply throw text in the box; it comes out looking as messy but it's mostly there and readable. People who care about how their text looks can do some simple things that are for the most part almost intuitive (like leaving blank lines between paragraphs, putting asterisks or numbers before list items) and it Just Works™
This is Good Enough™ for a lot of applications and people. Some of the glitzier sites, such as Google Blogs, give you your choice (changeable at the click of a button) of editing raw HTML or using a WYSIWYG editor (that fails just often enough that I usually opt for raw HTML). In theory, you could even give your users 3 alternatives, such as Markdown, HTML and WYSIWYG; but at some point you'll be wondering why you even bothered. Some users will always struggle with some aspect of the interface and they'll blame you. I believe in finding a happy medium and not bothering to make everybody happy.
From my point of view, the most important considerations are those of security. If you allow raw HTML, your users can insert spam and malware and basically hijack your site for their purposes; so you have to carefully limit what's allowed. Another consideration is that if you allow, e.g. H1 headers, people can take up a lot of space and attention with posts that should really be subordinate. If you allow CSS (including style attributes in HTML tags) then again there are ways to deface your "real" content. Another big problem stems from unclosed or unmatched tags. These are the really serious problems, and you want to err on the side of strictness to avoid more serious problems.
"What factors should I be taking into account when making this decision?" What do your customers want? Can you not have a 'fall back' kind of system where the 'simplified' WYSIWYG can be used until they need the added features of raw markup? What kinds of things do the most users use most often? What features are used less often but, when they are needed, you customers cannot live without?
"Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?" For people using wikis and blogs, I think the answer is yes. Even commenters on blogs to some extent for the simplest things but again, I think you should let them do markup in-line if they are able (or some common sub set of markup) and have the option of more power if they need it.
"..Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?" I would not take this all on at once. Work from a solid kernel of functionality and work outward to a complete system.
I'm writing an iPhone game and I am trying to write some requirements documents. I have never written requirements before so I got the book Software Requirements. I have not finished it yet, but I forsee some issues, as this book is targeted towards a business. My main question is I am the only person involved with this game and I feel the main purpose of the requirements document should be to nail out as many conceptual ideas of how the game works as I can before I am deep into design or construction. Does anyone have suggestions on how I should lay this out, should I still try to mimic the template provided in the book where it makes sense, or since I am both the sole developer and product owner, should I just stick to game concepts?
You're right that traditional SRS documents don't really fit games documentation all that well. Games instead have a general Game Design Document. It's usually created before any work on the game begins, and it's often edited as the development process goes to keep straight the intended end-result and specifics of the game.
While business software requirements documents are like contracts between a client and developer on what to produce, game design docs are more often specifications from the designer to the artists and programmers on what exactly they need to develop.
There is no specific layout to use. But you should consider who you're writing the document for. Is it for a class, for yourself, for peers after the project is done? The level of detail and the kind of things you include will be different depending on your audience. The format itself is very flexible, as long as it's coherent.
Brenda Brathwaite has a good blog entry on this subject which you might find helpful.
There is a semi-recent article from gamedev.net on the subject as well.
[Poor Jacob, you just read a book on the topic, and, collectively, the SO community writes another one for you, along with extra links, and probably with diverging views ;-) ]
Although I'm not familiar with the book you mention in the question, I think that the following suggestion may help you both take seriously, but also relax a bit, about the all too important question of requirements.
Being a "team of one", it is particularly important, and somewhat paradoxical, that you go through the effort of formalizing the requirements. However, rather than putting too much emphasis on the form, you may find an Agile approach to developement (and hence to requirements gathering) more appropriate. With regards to requirements, one of the main advantages of this approach, is flexibility, i.e. the understanding that while they should be formalized (with limited time/effort), requirements should be allowed to change (within limits) as part of an iterative process towards production of the target product.
In very broad terms, this generally go as follows:
write "user stories", these are individual "cards" (yes, physical cards, say 4 inches by 5 inches, are good, for you can then move then around, sort them etc.)
each story tells a particular feature of the application, here the game, from the end-user's perspective. You can/should start all cards with "As a user, I need the game to..." then follow with a particular feature, for example "... show my high score on the same page as the global high-scores are kept [because ... here optional reasons for why user may want this feature].
review each story and assign a rough estimation of the time involved in implementing it
review each story and assign a priority level (scale may vary, but something simple like "Must have from Version 1.0", "Should eventually be in there, for sure", "Would be nice to have" and "Maybe nice to have...")
organize releases, on the basis of what you can do within say 2 or 3 weeks, maximum. If a particular feature were to take too long, schedule it for a later release.
implement the features assigned to the current release
iterate through this release cycle, reviewing the requirements as you go, for the relative importance of features, and also the need of new features may become evident as with the insight provided by using the [incomplete/imperfect] intermediate releases.
Books like the one you describe are focused at a different audience, but there is value in the general concepts presented. Fully developed requirements documents are not as common as you might think. Don't let anyone think that you are a 'bad developer' for not having the most detailed requirements.
Requirements docs might be more important if you need to communicate the requirements with a co-developer.
If you are the sole developer I would strongly recommend that you spend your efforts on the design and implementation of the game, over requirements. If you have a good idea of what you build then let this flow as you build it.
Documentation can help you. The question is what is going to be most beneficial. Maybe design decisions are more critical than requirements for you but not for others. You'll maybe want to have a list of things that people have requested or ideas that you think of but cannot implement straight away. Sometimes a whiteboard can be handy for sketching out things, it's not just a tool for collaboration with other people.
Here's just a general approach...
Solidify the concept...write it in plain English first (ex: The game is a first person shooter. You kill zombies and hunt for treasure.)
Get a paper pad and pencil and draw out the general flow of the game and the main screens the users will encounter...main menu, options screen, help, etc. Make sure it makes sense.
Go to a site like mockingbird and create the detail wireframes for your screens...
Print these out and do some paper prototyping...i.e. put the printout in front of you and 'click' on a button...then bring up the appropriate screen...then click on another button, etc.
Once that makes sense, you can try to start coding your game.
Personally I believe you should use your own way to do this. The most commonly available one's will not match with your requirement. They might be suitable for a common commercial server application but not for a game. And since iPhone gaming is a new trend you may have to look in a different perspective.. You may not be able to fill a document with standard requirements and you may have different set of New type of requirements.
Just a suggestion... Sign up with Google Sites, and create a private site with documentation of the game, requirements, technical aspects, work log, etc... You can share it with select people, and it always keeps edit history.
I like it better than a Wiki because it is more structured, and just plain simple to use.
We have a user experience designer in our team who has no programming background. He is expected to design screens within Eclipse as a development environment. His (valid) complaint is that every time he designs a specific screen and gives it to development - they tell him what is not possible technically using either SWT or GEF. So, he wants me to teach him basics of SWT/GEF so that he can make informed decisions and maybe even try out certain things in eclipse (as opposed to using Photoshop) before proposing designs to save time.
My personal belief is that design should not be constrained by technical possibilities and in theory, everything that the designer dreams of (at least the practical things) should be possible technically - albeit with workarounds or a little hacking.
So, my question is this - how important do you think is programming knowledge for user interface design? And if it is, how do you go about teaching someone with absolutely no programming experience the graphical frameworks on various platforms?
In principle, I agree with you. Programming knowledge shouldn't be necessary to be a skilled designer of UIs and work flows. However, knowing the abilities and limitations of the technology in use can help a UI designer work more effectively with the programming staff.
Where programming knowledge can help is if the development staff is blowing smoke that something cannot be done when it can be, some knowledge of the tools being used can help refute that. If the development staff is correct that something cannot be done, then knowledge of the tools can help the UI designer find an appropriate solution that meets the design goals and is achievable.
With a properly cooperative development staff, the UI designer would need very little (if any) knowledge about the specific GUI tools being used.
I've been on the developer side of this where I was being asked to do something impossible or impractical. I always worked with the designers to find a happy middle that met the design goals. Sometimes what I thought was impossible was in fact possible. Sometimes we had to do things a different way. A few things had to be put off as "possible, but too much effort." (Such as an SWT based application that became a Windows task bar. Definitely possible, but impractical for the project in question as it would require native code.)
What is most important is that both sides realize that they are on the same team.
Its very important..
Not knowing about:
technology in general
the technology you have chosen to dedicate your time investing into to produce the end product
Will result in a complete waste of time for everyone..
Even the end user needs to learn a bit about the technology employed in able to use whatever product we make..
Someone who drives a car will always need to know how to fill in the gas and know the basics of what a car is and what it can do, software works in a similar fashion.
Its like asking someone who doesn't know that cars (the ones of today) need wheels to make a drawing of your next release model.
The way to make them more aware of the technology is:
Show him/her similar products to the ones you should be making
Show him/her stand alone implementations of the building blocks you might consider using
But by all means...this doesn't mean you should stifle their creativity..have them draw away what they dream, just make them that little bit aware of reality as needs be in order to have something done in this lifetime
So, my question is this - how important do you think is
programming knowledge for user
interface design?
I think a basic knowledge of the standard user interface for the platform is required (text fields, combo boxes, radio buttons, etc). A good designer should be familiar with the capabilities and limitations of these GUI components, from a developer's point of view. So I guess some basic programming knowledge would be useful.
My personal belief is that design
should not be constrained by technical
possibilities and in theory,
everything that the designer dreams of
(at least the practical things) should
be possible technically - albeit with
workarounds or a little hacking.
I think there are important qualifications here --- each OS has guidelines on what constitutes good GUI design, and it's beneficial for your product that you follow them because the user has a certain mental model of how he or she should interact with applications on that platform. (Having said that, there may be good reasons for breaking some design conventions, e.g. in games, specialized graphics/music applications.)
how do you go about teaching someone
with absolutely no programming
experience the graphical frameworks on
various platforms?
Each toolkit makes available a whole bunch of small sample programs to demonstrate the use of different components --- this is probably a good first step to acquaint oneself with them.
Is not as important as common sense in my opinion.
It helps of course. But if the designer is asking for something that could be done ( because some other application uses it ) the development lead should at least present a workaround.
Programming knowledge probably not, but limitations on the chosen platform certainly.
I think it's better to learn up front, but if your UI designer is forced to learn on the fly, make sure that each time he is turned away, it's explained why something can't be done rather than just a flat refusal. This will keep him from getting as frustrated as he might otherwise be because he'll be able to form at least some logical framework for what he can and can't do.
I think the designer should be aware of the features and limitations that the tools he's using offer, and he should be aware of the limitations and the deadline of the current project that those guys are making.
He should also be aware of the background processing that's going on to show the screen UI, and all these things will come only if he has some rudimentary knowledge of programming.
He doesn't have to dabble in the depth of OOP, learn SQL, know the intricacies of reflection or anything fancy like that. He just has to know his platform well, and that I think is a requirement even for the designers.
The very core of "design" is to find a way to achieve a desired result within the constraints. If you don't anything about a part of the constraints that affects your goal, then you can't design.
It all depends on your tools.
Edit: What I mean is there are tools that are designed for designers, and tools for programmers. Eclipse, for one is not a designer tool. Photoshop is. Flash maybe, Flex not. I wouldn't require a Flash designer to program, but a Flex designer does need to program.
As for telling them about the limits of your tools it depends, really good creative designers will embrace those limits and make incredible work, mediocre designers will perceive the limits as roadblocks and stop being creative and just following the rules with fear.
I have given it some thought and based on the answers given previously, i have reached certain conclusions:
A preliminary knowledge about what is possible and what are the constraints while designing on a given platform is mandatory. This means that the graphics designer should be aware of the following:
The basic design guidelines on that platform
The standard UI toolkit / widgets provided on that platform (for ex: textboxes, drop-down lists, etc)
What is not possible (or is too cumbersome) on a given platform (for ex: creating translucent modal dialogs while fading out the background in Eclipse)
This amount of knowledge might not require the designer to dabble in programming.
The second level is where the designer is making an attempt to either create new widgets or to (knowingly) go against the set standards for a given platform. For instance, if the design includes graphs or the need to depict special relationships or a unique combination of text, graphics and images that is not implicitly supported by any standard toolsets. In this case, the designer should be aware of the technical possibilities and the limits of a given platform. In this case, i would argue that the designer should be able to write a little code and try out a few things to ascertain what might be within the realms of possibility.