There is not official standard dealing with the layout of about boxes, which display the credits of a computer software and other information.
What should a good about box contain? And... is it okay to put an easter egg in?
(source: seasip.info)
I generally prefer to make tabbed "About" boxes. The first tab usually displays information about the application (name, version, copyright, etc.). The other tab is usually a log of changes with the most recent changes at the top.
Legal will want their copyright and stuff, marketing will want their branding (even though the user has already bought the product), the dev team will want their names up there in liquid crystal, but what do users need?
App name and version number. Users may need this to troubleshoot problems, perhaps while in contact with tech support or when using a knowledge base. Use a version number system such that this is all the user needs to specify their build. Version number is also needed for the users to know if they can upgrade.
A brief statement of what the app does (e.g., “Photograph and picture organizer.”). Users often end up with software for which they can’t guess the purpose. “About” is a logical place to tell the user what the app is about.
Put the above in conspicuous text at the top of About. Have a single OK button. Everything else that may be required by others in your company really isn’t of any interest to the user and can all be in “fine print.”
You could also include the web site or email for tech support if you can rely on that being stable for years, but usually users have this before going to the About box.
Easter eggs are fine if you think it’s appropriate to have a little fun in your app and your users lean towards the geeky side of things. Just make sure it isn’t something that will alarm a low-end user (or a future high-end developer; see: http://blogs.msdn.com/jensenh/archive/2005/10/20/483041.aspx).
Looking at a few examples of About boxes:
Name of the software
Name of the publisher/author
Copyright and licensing information
Version information
A nice logo
These days, it probably wouldn't hurt to have a way to directly go to the website for the software in the About box itself.
Microsoft's Windows Vista User Experience Guidelines tend to have useful information on designing good user interfaces. I wasn't able to find information specific to About boxes, but the section for Dialog Boxes may be somewhat relevant.
A team in my workplace actually has made the coolest About box ever:
Every time you open it, it displays a different simple game, with pictures of the dev. team (memory games, tic-tac-toe, sudoku, etc)
As for the About page content, that is the best place to have the version / release information so you can offer easy support.
I am using mine as the abstract description and a link to the legal pages and a credits page. If you have a website, its URL should be there as well -- might as well make that click-able into your own web-view browser to your big "Company About" page on your web server (don't launch a real browser, or the user just left your application).
Make it enjoyable to read but be concise. Avoid any scrolling or paging -- except to a completely different set of informational screens.
Also, let it be obvious and easy to dismiss.
By-the-way, if you add an easter egg to an app that is submitted to Apple Store, you have to disclose the sequence for Apple to 'test'; they promise to keep the sequence confidential. If they discover it later, which will make it back to them through forums, etc., then they will automatically pull it from the store.
I tend to add program name, version, company copyright, contact information, license information. I also add various variables for problem resolving. Winows version, servicepack, dll version if i use critical dll's etc. A large application icon. Sometimes I add an easter egg or some keycombo that launch parts of the program meant for debug and support purposes.
Related
I'm aware this isn't exactly a programming question, but it directly impacts our developers and the code we're assigned to write. If there's another SO-like forum where this could be better posted, please let me know and I'll take the question down from here & post it there.
Our work environment is a couple of developers creating (20-30%) and maintaining (lion's share) legacy software for factory production floor and test workers to use to calibrate or test the equipment the company sells. We've implemented a very simple Google form based bug reporting page, but we're already running into problems of scale (approx 40:1 them:us and lots of old-old buggy software that we didn't write). The company has tried using Bugzilla before my arrival with little success, the factory folks were apparently intimidated by it and wouldn't use it. However, they seem to like the simple Google form and the wizard-like steps to file a bug or request a feature. We're currently manually cutting & pasting their bug/feature requests from the Google form spreadsheet into Trac, and manually tracking the bugs/feature requests on a white board with magnetic bug cards. We're only a few weeks into this system and it's already showing it fragility and lack of scalability.
Ideally we'd have a Windows >= XP web or desktop client that would provide:
Simplified bug reporting, a Wizard like approach seems to work well
Customizable for our software packages (like drop downs for each)
Bugzilla or Trac integration
Standard bug tracking features developers and management can use
I've found the winners of the "Make Bugzilla Pretty" contest, but coming from a pure software house where we just used straight Bugzilla out of the box, I'm unclear on how to configure and install these skins. Obviously I can figure this out but don't want to go down that path if it's not going to solve our basic problem which is non-technical people reporting bugs.
TaskCompiler, found on the Bugzilla wiki site seemed like a candidate because it talks to both Bugzilla & Trac, but their sales page is offline and the site hasn't been updated since 2012 and I'm unsure as to their viability.
I'm certain we're not the first production facility to run into problems like this, I'm looking for recommendations to help solve both our scalability as well as-ease-of-use problem.
Another thought that occurs to me is a GAS script to push our current Google forms based bug reports into Trac or Bugzilla.
Edit: The decision between Bugzilla/Trac seems to have been made for us. I'm exploring options for using Trac here if you want to follow along.
I recently had my app certified (first time!) but not automatically published. The game is Easter themed and hence I'd like it to appear in the new list over the Easter period. I need to know how best to achieve this.
According to many posts online, the 'new list' isn't sorted in order of release date but instead, in order of certification date, an automated system, the certifiers choice etc.
Thre are some theories here:
http://forums.create.msdn.com/forums/t/85466.aspx
https://stackoverflow.com/questions/6536557/first-time-game-shows-up-way-down-the-list-of-new-free-games-on-wp7-marketplace
Both of these posts are in 2011 and aren't conclusive.
Does anybody know what ACTUALLY happens?
Thank you for any reply.
In my experience, the new apps are changed once per day or in a similar fashion. Again, from experience, you can't do anything to ensure that your application is first. However, I have manually published applications after they have been tested and approved and they were listed in the 'new' category as if they were published that day.
Usually, don't worry because your app will be listed in the first 20 of that 'day' at least once and if you get - or set ;) - some high ratings people will see it.
I found this out the hard way. The plan was to release to a few small markets to get some feedback and then do an update and release to the USA. Well, once the game was released to the USA it was not considered new and did not go into the NEW GAME list. It retained the release date of the initial release to the small markets. And as such, I totally missed out on the new release spike that we all have come to love and enjoy.
Check out Alien Escape
Game Trailer http://www.youtube.com/watch?v=kWE6Dlk6xpc
I have some apps on marketplace already. I can talk from experience. The release after you have published will depend on countries and will delay without fully control. Also if you don't make any advertisement, it will not work with only "keywords on marketplace". I have solved by using my own Webservice and I flagged the app with "LOCKED" view. On EASTERN you can unlock the app by using your Webservice flag and immediately when the app starts, user can use it UNLOCKED.
No other solution is working in time usable way. But I fully like it to have my own app under full control. Also, I have added an "Code behind" for Testers to let them test the app before EASTERN.
Happy eastern
With the advent of the new marketplaces, Microsoft disallows certain language and content in certain marketplaces.
For example, the Chinese, Indonesia and Malasya markets do not allow references to alcohol - any references to alcohol.
One of my apps has a single string that contains the word "alcohol" in it and is thus disallowed. I was wondering if there's a progammatic way of discovering what marketplace a phone is attached to and thus remove the string in those cases.
I can of course submit 2 different XAPs to the marketplace, but I would hate the hassle of doing that.
There is no API to guarantee to return which marketplace the LiveID of the currently logged in user is associated with. Even if there was there would be no way to test this on the emulator, as it doesn't allow you to log in so you'd need multiple accounts, each with different marketplaces and to avoid the need to repeatedly hard reset your device you'd probably want multiple devices too. (THis may or may not be an issue for you.)
For your situation you'll need to submit multiple XAP files or remove the alcohol reference from all versions. The verification for this requirement is not done with devices associated with each marketplace but typically just done on a single device and so attempts to get around your situation in the way you've described wouldn't work.
Alternatively, you could localize the app appropriately and just not have that section in the localized versions for those countries. I'm not sure if that would be enough to meet the marketplace requirement though as users in those countries could still set their devices to another region/locale.
As a general guide, you could attempt to infer the marketplace the user is most likley to be connected to based on their location or regional settings but this wouldn't be guaranteed. Asking (to confirm) would be the best bet, but not in your scenario.
The team I'm working with have created a CRM4 add-on which encapsulates 'standard' CRM customisations (such as modifying existing entities, adding our own custom entities), reports, plug-ins, and our own web pages (in IFrames) and web services. All pretty typical stuff.
I'm writing all the requisite installation code to simplify / automate the install process so that our ISV add-on can downloaded and trialled by anyone, but have been asked to think of appropriate way restrict functionality - to encourage people to purchase a license.
I'm not that familiar with the concepts/best practices/pitfalls when it comes to the 'licensing' of .net apps (especially CRM4 add-ons) so am asking you if you have any suggestions. We're looking for something fairly simple, and should be reasonably 'crackable', since we believe that having to enter a license code is generally a PITA.
Does the CRM API have anything to offer the ISV developer? (I see that one is able to nterrogate the License entity, but I'm assuming that this is for the CRM license itself)
Are there any existing code samples / projects / frameworks that are appropriate to use or implement?
I'm tempted to create a Registry Key upon installation of the add-on which, if after a month the correct license key has not been entered, will restrict functionality. Is this the best way to do this? Have you seen any other add-ons do it differently / better?
In terms of restricting functionality, I'm thinking of throwing InvalidPluginExecutionExceptions. Surely there must be a more 'graceful' way to do this?
All thoughts and suggestions appreciated.
Regards,
Peter.
My thoughts:
Yes, you can query the License entity to get the number of licensed users, which is a common license type from what I've seen. Lots of 3rd party vendors charge by the number of licensed users, regardless of how many of those users actually use the customization. I try to stay away from these because the license costs are often prohibitive for enterprise deployments.
Not that I know of.
I like this option, and have seen at least one 3rd party tool use this method. They allow you to declare the license key in your .config file, and if their runtime doesn't find it there it checks a known registry key. The tool comes with an app that registers the license key in the registry for you. I'd be careful to test and make sure your custom code can read the registry in a least-privilege environment.
Definitely not graceful to throw exceptions, but it does prove your point. :) Other than that, just outright skipping your code is another possibility, although that could have data implications. If you must throw exceptions, I would suggest trying to run some javascript on form load of your entities that warns the user that their license is expired and a save will result in an error. Some more nefarious schemes could include Thread.Sleep, kinda like the old shareware nagscreens. :)
Another idea - can you set up an Enterprise IFD deployment so you can give customers remote access to your demo, including their own demo organization? This depends on your audience, but your customers may not have the luxury (time, dev environment) of downloading and installing your trial. They may just want to see it in action - once you qualify the sale maybe you offer free remote installation and not spend so much time on a flawless setup package? Again, depends on your audience and the volume of licenses you expect to sell. Technically, you could dynamically provision organizations using the SDK and make the online trial process completely automatic. Of course this is a big investment, but allows you to maintain absolute control over your demo/IP.
Hope that helps!
So I just started an internship with this nonprofit company and it's pretty cool. My first assignment was to find a type of program that would work well for the company and its users. I and some team members just finished summarizing down what I think is a good list for the needed functionality. Before I started working, I've never even heard of content/document/knowledge/project management systems. So I've done a bit of research on many other programs and I've narrowed it down to Joomla, activeCollab, Basecamp, sharepoint and a few more. Which program out there would fit my needs the best? It doesn't have to be from the list I just wrote, those are just the programs that popped up first when I started searching.
MUST-HAVE CAPABILITIES
Searchable
Keyword search
Advanced search: Ability to tag & search documents by different categories, for example, type of file (e.g. PDF, Word, etc.), service line (e.g., fundraising, strategy, etc.), type of document (e.g., deliverable, data set, etc.)
In-document search
Categorization
Simple navigation to browse all content
Simple to set up and modify the tree/hierarchy used to browse content
Workrooms
Provide each team a separate workroom to post their own documents
Easy to navigate from team workrooms to the Toolkits (best if team workrooms reside in the same system the toolkits reside)
Version Control
Ability to see which is the most recent file
Security
Password protected
Tiered security, i.e. certain permissions for certain users (to create workrooms, change navigation tree, change toolkits, view/post team files, etc.)
Multi-year support
Easy to “archive” old workrooms or files so the navigation doesn’t become cluttered over time
Share across workgroups
Ability for power users to access multiple team workrooms
Ability to send docs from one group to another—or to the toolkits (by simple tagging or simple “submit” feature)
Uploading
Ability to upload files to workrooms
Ability to submit a new file for consideration for a toolkit (not a file currently in any workroom)
OPTIONAL CAPABILITIES
Messaging
Opt-in notification of uploaded files or changes to existing files
Version Control
Ability to see who has the file checked out
External Access
Client access to certain documents
Within our website
Users gain access from our website
It looks like it resides on our website
Collaboration Tools
Team Calendar
Blog / Forum
Instant Chat
WebEx/Remote Presentation (for virtual team meeting)
Ratings
1-5 Star document rating (by user community)
Searching & Sorting documents by rating (best documents display first in search results)
Simultaneous Edit
Multiple people can edit the same document at same time
Workflow
Ability to tag a file to be reviewed by another user (ability to “escalate” a file for review by someone else)
Messaging alerts when a file has been flagged for a user
Most of the features that you mentioned above are available for free using Plone, which is an application that runs on top of Zope. I actually built and deployed an instance of Plone for a non-prof that had a lot of the features that mentioned above. They features might not have had the same names, but you get a lot of the same functionality.
Here's what my users really liked about Plone:
The ability to index the content of MS Office documents, so that people could search for documents based on content in addition to property and tags/keywords.
Usability. The default theme for Plone isn't the flashiest thing that you will ever see, but it's usability is excellent.
How easy it was the change the system and add new sites or functionality.
Here's what I liked about Plone:
Zero licensing costs. I was able to implement features that usually only come in very expensive systems for free. And I'm aware of these types of costs, because I administer FileNet systems for a living
It was very easy to install, upgrade, and administer. Please take that "pro" with a grain of salt if you're not a professional systems administrator :)
Overall, it was just very easy to work with.
And here are my cons:
If you need the web site to be accessible on the public internet, then your hosting costs may be higher-than-expected. It's definitely cheaper to set up a vanilla Joomla site than it is to set up a vanilla Plone site. Please note that you sound like you need a lot more than a vanilla content management system, so their may be no difference in hosting costs.
Plone is built on Zope, and Zope is an application server. It's easy to set up and use, but it works a little differently than a lot of other web and application servers. If you're used to administering a LAMP stack, then this will be different (but not necessarily bad).
One final con is true with all modern content management systems: don't give your users enough rope to hang themselves. When it take 2 minutes to a wiki and a blog to a web site, then users expect you to add new sites all of the time. Every new site adds a lot of administrative work to your plate, so try and get as much functionality as you can from each site that you add.
Hope that helps!
Tom Purl
Basecamp. Even if it doesn't have all the features you think you need, it does what it is supposed to (37Signals loves to rant about too many features, you aren't gonna need it (YAGNI), etc.)
Joomla is a pain. Activecollab is a poor clone of basecamp (unless it has changed drastically in the year or so that its been since I tried to use it to get out of paying for basecamp).