Related
Does Apple provide developers a set of standard terms in differing languages? The reason why I ask is that I'm having portions of my application localized and want standard terminology consistently applied throughout the app. I have utilized some tactics to do this with terms like 'Loading...' by changing the language on my device and observing how Apple has interpreted those terms in other languages. This has only gotten me so far however, and a resource that I can give a translator would go a long way in creating a seamless experience with the consistent application of terminology.
It has been two and a half years since posting my radar, but Apple has finally posted its iOS glossaries:
You can download them from developer.apple.com, or use this link to quickly find them:
https://developer.apple.com/downloads/index.action?name=Glossaries%20-%20iOS
EDIT 29 FEB 2020: This link is still valid and the glossaries have been updated on 15 JAN 2020 with everything updated for iOS 13.3.
At WWDC this year I went to the Localization Lab to get an answer to this question, since a bona fide answer from Apple was needed.
From one of their head cheeses in localization he told me that currently there are not any publicly available resources for download for iOS or Snow Leopard. He did tell me, though, that these resources were slated for release in the coming weeks after WWDC.
This answer will be updated when the information becomes available.
UPDATE 19 JUN 2012: Wow, it has been a whole year now! Obviously Apple didn't come through for us 'in a few weeks'. I did talk to them again this year and was given a contact to follow up with via email. I explained that they made a claim to have it last year and this was the response I got:
I did check with the documentation folks and found that they're still
planning on doing this but it's fallen behind other priorities. If you
haven't already done so, would you mind filing a bug report about
this? That's one of the best ways to convey the desire to the
appropriate people. While I've relayed this feedback to some people
it's always best to have a bug report directly from folks outside of
Apple. Feel free to forward me the bug number and I'll keep an eye on
it.
Our best bet at this point is to keep filling bug reports so that this gets more attention. Just for the record, I did file a bug report last year.
Apple provides a number of translation resources that you can download which may or may not be useful. One of these is AppleGlot, a tool for replacing strings in application resources. A number of XML-based glossaries for different languages are also available, but they're specific to AppleGlot. You may be able to make AppleGlot work for you, or you might just want to extract what you can from the language glossaries. AppleGlot and the glossaries were created to support translation of MacOS applications, so the terms are related to MacOS X and not iOS. Nevertheless, I think it's worth a look.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
My company is trying to pass a policy forbidding distribution of any application (even free) in any appstore for all developers.
Their reasoning is that "outside work activities create a conflict of interest". They don't want that "you use your spare time to work on your app, and once it takes off you quit your job" (quoting the Head of Development).
A few developers (myself included) have already said it was an abusive, pointless and most of all counter-productive policy (developers will actually be demotivated to work here under such control and to be denied of the freedom to distribute their project).
Personally, I think it is actually in the interest of the company to promote side projects (even commercial activities, if there is no conflict).
I'm also curious, is that common practice?
Needless to say, this is horribly, horribly stupid on so many levels... It may be worth trying to find out whether it's even legal in your jurisdiction.
Anyway and apart from that, if you can, find colleagues who feel the same, and take a stand against it. Try to explain to the management that this is a stupid decision for the company as well. Don't sign anything: A policy like that would probably have to be amended to your work contract to be binding. Chances are, the risk of losing good employees over this outweighs the security they think they get from it.
If there's really nothing that can be done, and you are very unhappy with this (I would be), consider looking for a new job.
As an afterthought, if the practice of limiting your employees' rights to this extent is clearly illegal in your jurisdiction, it could be that simply making them aware of this might stop this without any further trouble.
All companies for which I have worked allowed outside work provided:
no company resources were used (this includes time)
the product of that effort did not directly conflict with the company's interest
the product was not based off of work or specific knowledge gained while working for the company
Typically, companies have a clause in your employment agreement that states that you will inform them when you begin work on outside projects and inform them of the nature so they can approve/deny. In such cases, you want to get that approval in writing.
In your case, this is a pretty difficult situation if this was part of your employment agreement. Even if it isn't, they can fire you for it if your employment is at-will and they find out. Unfortunately, in your situation, you seem to have one of four options:
Convince management that they are being unreasonable.
Fly under the radar and hope you don't get caught.
Find a new job.
Quit and just work on the apps full-time.
If your job is to put out apps in an appstore, though, there's really no way to argue that your outside development of apps for the same appstore isn't a conflict of interest in some respect. If I had to guess, I'd say that either this is the case or you're working for a development manager that doesn't understand the mindset of developers and how they like to tinker and learn outside of work.
While this example sounds a little draconian, it is not uncommon for companies to have some kind of policy regarding outside work. However, this is typically to protect the company from your mistakes rather than to protect them from your departure. If they're that concerned about employees leaving, they should go out of their way to make it the sort of place you would want to stay.
EDIT: I just found this today on a completely unrelated blog, but it totally rings true to this discussion. It's about 11 minutes long, but very entertaining and makes you think too. http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_embedded The TL;DR (TL;DW?): Once you get outside the realm of purely physical tasks, organizations that assume you are motivated by money, hands-on direction, etc. will not accomplish their goals nearly as easily as those that assume you are motivated by desires for autonomy (self-direction, self-management), mastery (getting better at doing something) and contribution to something bigger than yourself.
I believe there was a similar pointless rule when I was under the corporate yoke. I think these rules are pointless, backward and wrong. Instead of keeping their developers management pushes them to look for new managment, well, at least the passionate and talented ones.
Unless your employment contract says otherwise, what you develop in your own time belongs to you.
If they are in the business of writing apps for the appstore, then they might have a non-compete argument against you.
If they allow other types of development projects, it is difficult to see the argument as valid.
Depends on the app and the company.
If you're working for an Android app developer, I'd see why they might not like it. 8)
If it competes directly with what your company produces I can see why they'd prohibit it.
I would consult a lawyer to see just how binding such an agreement would be if you were forced to sign it.
If it's really that odious, your only recourse is to find another employer.
Check your local labor laws. In California, this kind of thing is blatantly illegal.
The policy enumerated by Shaun is reasonable, and something very similar has been in place at most of my previous employers. The one place that tried something like this was quickly pointed at the statute by knowledgable developers, and the "policy" quietly went away.
The answer is in your contract of employment.
But if your job is as a computer programmer, you're almost guaranteed to have something in your employment contract stating that any software you write either in work or outside of work is owned by the company.
If you get written permission from HR and your manager, then if you were to make millions from you out of hours projects, then it would be more difficult for your employer to just take ALL those millions off of you.
I was recently asked by a Team Leader (not mine) if I would be willing to undertake a programming project. The members of his team are currently pre-occupied with other more important projects. I graduated college two years ago, and up until now programming has only been a hobby of mine. Recently I decided that I would like to pursue a career in software development. I accepted his offer so that I can gain some real-world experience and start building a portfolio.
In about an hour I'm scheduled to meet with the Team Leader to discuss the details of what he needs. From a short e-mail exchange with him, I know that the base project is to update an existing ASP.NET form—but I also think there's more to it than that.
Considering that I'd like to eventually put this project in a portfolio, what kinds of notes should I take at the meeting?
Take whatever notes you can that will best help you understand the use cases and the user requirements. Everything else is just technical details that can be figured out later.
I graduated college two years ago, and up until now programming has only been a hobby of mine.
In that case, my suggestion is:
revel in your ignorance.
Make the most of the fact that you know nothing and you're being given an opportunity to learn - abuse the chance to ask as many questions as possible of the Team Leader in question regarding what type of questions you should be asking and how you should be documenting what you learn.
You only get one chance to be ignorant, once you've wasted it you have to spend the rest of your life as a know-it-all; take the chance to enjoy the learning process.
Get a list of people who are the intended users. Talking with them will allow you to flesh out the overview that the Team Leader gives you. It is likely that the intended users have a very different understanding of what the app is supposed to do than the TL does. So you'll likely be going back and forth for a while. It's well worth the effort though because you'll do much less re-coding.
Try to understand that the Team Leader him/herself might not even have all the requirements available right at the beginning. Be prepared to be hunting down people and writing all these requirements down as they come in.
Things will change during development, new problems and new requirements will always be popping up.
Three things:
What: What is the software supposed to do, the more detailed you can manage to get the other person to be, the better.
How: Are there any known constraints? For example, if it has to ask for a telephone number, does it have to validate nationally/internationally/not at all. Does it have to run on Windows 2008/2003/all
Who: Two sides:
Who will answer any questions you'll have, will you setup weekly progress meetings?
Who will use the software, can you get their early input on your prototypes, can you ask them for opinion/requirements?
One thing I've found very helpful is carrying a hard-copy of any existing requirements (use cases, wireframes, whatever) or any other potentially useful information in a 3 ring binder to any project meetings I attend. If the meeting strays off topic or questions about previous discussions or documents come up it is very nice to have the information at your fingertips in a format you can make notes on, pass around the table etc.
As a bonus, I find most people don't carry any documents to meetings, so you'll also end up looking like you are a real go-getter who is always prepared, which is never a bad thing.
Main downside to this is that you'll waste paper if the documents are updated and changed frequently.
Find out the where as well, where are the files you need stored on the network, where is the source control repository for the project, etc.
Since this is your first taste of doing a real world project, please please please make sure you use source control even if you are the only dev on the project. Your co-workers will thank you and you will thank you the first time you need to back out a change that didn't work.
Hi I'm currently doing some independent development on the iPhone and Mac. Loving the freedom but the single biggest thing I miss about working with a team of developers is the opportunity to talk through design choices and issues with other developers.
I'm not talking about general "humm ..." questions (there is stackoverflow for that ;)) I'm talking about things that are not for public consumption or are very specific to your application. I'm thinking about something that is a little more interactive (for example screen sharing and chatting).
Does such a thing exist?
There are Cocoaheads groups in various cities, that usually have monthly meetings... also there are NSCoder groups, that have a bunch of people working together for a day or so once a week.
IRC sounds like a good place for such discussions. Some iPhone development related channels you may be interested in:
[I don't know any, community wiki'ing this so others can add them]
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working in a small company and weeks away from deploying a web-app that will be used a lot. Everyone at one location will have to learn to use it, and although I think it's pretty easy and intuitive I may be biased.
I've written a help guide with plenty of screenshots that's available on every page, but I'll still need to train everyone. What's the best way? How do you take a step back and explain code you've been working on for weeks?
First try to avoid the training:
Perform usability testing to ensure your web app is intuitive. Usability testing is a very important aspect of testing and it is often ignored. How you see your system will probably be very different as how a new user sees your system.
Also add contextual help as often as you can. For example when I hover over a tag in stack overflow, I know exactly what clicking it will do, because it tells me.
Also this may seem obvious, but make sure you link to your documentation from the site itself. People may not think of looking in your documentation unless its right in front of their eyes.
About training documentation:
Try to split up your material into how your users would use the system. I personally like the "trails" option that Sun created for their Java tutorials. In this tutorial you can do several things, and you can chose on which trail you'd like to go.
Support random reads in your help documentation. If they have a task to do in your web app, then they should be able to get help on that without reading a bunch of unrelated content.
Make sure your documentation is searchable.
About actual training sessions:
If you are actually performing training sessions, stay away from explaining anything related to your code at all. You don't need to know about the engine to drive a car.
Try to split up your training sessions into very focused aspects of your system. If you only have 1 training session available to you then just do one specialized use case of your system + the overall description of the system. Refer to the different parts of documentation where they can get help.
Letting the community help itself:
No matter how extensive your documentation is, you'll always have cases that you didn't cover. That's why it's a good idea to have a forum available to all users of the system. Allow them to ask each other questions.
You can review this forum and add content to your documentation as needed.
You could also open up a wiki for the documentation itself, but this is probably not desirable if your user base isn't very large.
Few ideas:
Do you have some canned walk-through scenarios? Don't know if it is applicable for your product, but I built a pretty substantial product a couple years ago and developed some training modules that they'd work through - nothing long, maybe 15 minutes tops for each one.
I put together a slide presentation that hit the highlights to talk about what it does. I would spend about 10 minutes going through the app's highlights to familiarize them with it before doing the hands-on stuff.
People don't tend to read stuff, unfortunately. You could put hours and hours into a help document, and still find that folks simply don't read it or skim over it. That can be frustrating. Expect that answers that are in your guide will be the topic of questions your users will have.
Break up any training you do into manageable chunks. I've been to a full-day training exercise before and the trainer broke it into short pieces and made it easy for me to get the training topic in my head. You don't want to data-dump on them because their eyes will gloss over and you'll lose them.
Ultimately, if your app is highly usable, it should be a piece of cake. If it isn't, you'll find out. You might want to have a few folks you know run through your training ahead of time and give you constructive criticism on it. Better to fix it before the big group is trained. You'll be more confident in the product and the training materials (whatever they are) and you'll likely have a better training experience.
If applicable, provide an online help/wiki/faq for them. Sometimes that is helpful.
Best of luck!
You should really have addressed this issue a lot earlier in the development cycle than you are doing.
In my view the ideal scenario for corporate software is one where the users design their own application and write their own documentation and I always try to strive for this. You should have identified key users early on and designed the system with them (I try to get my users to do basic screen designs and menu layouts in Excel or similar - then I implement that as static pages and review before writing a line of significant code, obviously they won't get the design right first time, but it's your job to guide them - and ideally in a way where they think they came up with the correct design decisions, not you :-) ).
These users should then write the user documentation from this design in parallel with you developing the system. I have never seen help documentation delivered by a IT department/software company used significantly in a corporate setting. Instead what happens is the users will create their own folder of notes and work-arounds and refer to this (in fact if you're ever doing system analysis to replace an existing system finding the 'user-bible' for the old system is a key strategy). Getting the users to write their own documentation up-front simply harnesses what will happen anyway - but this is vastly easier if the users feel they have ownership of the system because they designed it themselves in the first place.
Of course this approach needs commitment and time from your users, but generally it's not that hard a sell. It's trite, but working as a facilitator so the users can develop there own system rather than as a third party to give them a system pretty much guarantees user acceptance.
As you are where you are you're too late to implement all of this, but if you can identify a couple of keen, key, users and get time from them to write their own documentation then that would be a good move. If you can't get even that then you need to identify an evangelist who you can train to be the 'departmental' expert and give them 110% of your energy to support them.
The bottom line is that user acceptance is based on perception, and this does not necessarily correlate with how usable an system actually is. You have to focus on the group psychology of this as much as the reality of the system, which tends to be tricky for developers as we're much more factually based than most people.
I'll be looking into something like this too in the next few months.
In your case, hopefully the UI has already undergone user acceptance testing. You say you work in a small company. Is it possible to get the least tech-savvy person there to try it out? In fact, get them to try it out without any guidance from yourself except for questions they ask. Document the questions and make sure your user-guide answers them.
The main thing for me would be logic and consistency. If the app's workflow relates logically to the task it has been designed to accomplish and the UI is consistent you should be OK.
Create a wiki page to describe the use of your system. Giving edit rights to the users of your system lets the users:
update the documentation to correct any errors in the initial release of documentation,
share any tips on usage they may have found.
share unusual uses for the system that you may not have thought of.
request features.
provide any workarounds they've found while waiting for the new functionality to be implemented.
Try a few users first, one or two in a small company. Mostly watch, help as little as possible. This tells you what needs to be fixed, and it creates an experienced user base - so you are not the "training bottleneck" anymore.
Turn core requirements/use cases/storycards into HowTo / walkthroughs for your documentation.
For a public training, prepare a 10..15 minute presentation (just that, not more!) that covers key concepts that the users absolutely must understand, than show your core walkthroughs. Reserve extra time for questions about how to solve various tasks.
Think as a user, not as a techie: - noone cares if it's a SQL database and you spent a lot of time to get the locking mechanisms right. They do care about "does it slow me down" and "does something bad happen when two people do that at the same time". Our job is to make complicated things look easy.
It may help to put the documentation on the intranet in an editable form - page "comments", or wiki maybe. And/or put up a "error wiki" for error messages and blips - where you or your users can quickly add recomendations, workarounds and reasons for anything that does not go as expected.
Rather then train all those people I have chosen a few superusers (at least one person from each department) and trained them to teach the rest of the employees. It is of course vital that those super users are
well respected in their departments
able to teach
like the application
The easy way to ensure that they like the app is to have them to define the way it should work :-). Since they should work with this app each and every day they are the prime stakeholders, no matter what management states