first, some facts:
1 - people (devs) are working on these projects in their free time - they are not paid
2 - they do not have to share their work with anyone
3 - all code on this site is optional - you do not have to download or use it
4 - to really get the code working the devs need testers and feedback
5 - testing and feedback requires time and effort
There is a distinction between a tester and a user. A tester will generally start from a known baseline, add whatever specific changes a dev wants and then run that code. If the code breaks, they will try to repeat that problem. While repeating it they will activate logging software and meticulously record the steps leading to the break. If it breaks again during the repeat they then file a bug report (with log outputs) to the dev's thread. The dev can then look and see what went wrong and try to improve the code. There is a specific process associated with doing all this and it does require a certain type of knowledge.
A user generally just wants usable and well working code. They either don't have the training or desire to test or develop. The 'stable' code is included in the major releases. This is not perfect code, only code that has fairly well defined issues. At release these issues are generally identified. Users have jobs too. Their job is to provide motivational support to keep the developers interested. They are the fanbase.
Think of the developers as a music group or a director or a writer. The testers are their focus groups, editors, and producers that provide direct, detailed, and actionable feedback. The Users are the fans, enjoying the art, movie, book, code whatever. If a user didn't like a band, movie, or book - or the people who generated these things, they should not read, watch or listen to said item. In other words, the developer is putting something out there for enjoyment to the Users - not for feedback from the users unless they specifically ask for it. If this was a concert, book signing, movie theater - all the people making trouble would be escorted out by security.
In the commercial world the devs and testers are paid with money by the users. In the volunteer / free world the only currency is your appreciation. In other words, if a user chooses to download and use code, they should express their undying gratitude, or delete said code and move on with their lives. Users repeatedly having a certain issue or outright attacking a volunteer dev or tester is unwelcome and unwarranted. These type of actions create negative feelings and decrease the likelihood of any additional work being done on this project. There's a saying that goes along with this. If you can't say anything nice, don't say anything at all.
Related
First I would like to thank the whole forum (with few exceptions that I'd like to not mention here) for the past 2,5 years, which have been very educating for me regarding Windows Mobile as a system. During that whole time I have searched for the perfect simple-to-use, lightweight app for storing and retrieving a grocery list, yet unfortunately I have had to come to the conclusion that it does not exist to this date. There are some existing apps but these are either not simple to use or do not accomplish the simple task at all, or they are too heavy (requiring additionally the .NET framework to be installed for example, etc.).
The idea for the simple software is that one has a changeable groups and items of groceries, from which they can select the already saved ones needed at that shopping day (e.g. during a discussion with girlfriend), and later when in shop they can just check the ones they have already put into basket. I would like to see the person who will argue that it does not easily beat archaic mode of storing information, a.k.a. paper and pen.
I have found an app which, with some relatively small amount of effort can be rewritten to accomplish that task, this software is iContact AE. As far as I understand, there is judicially no problem using the source code from iContact AE as long as following the license restrictions (correct me please if I am wrong). Why AE? Just a selection based on the fact that AE has the most appealing interface and most settings. Of course, this could be a point of discussion, but so far it seems like the best choice.
CAB - http://icontactae.codeplex.com/releases/view/28951
Source - http://icontactae.codeplex.com/SourceControl/list/changesets
I created a possible, chronological tasklist in order to get from iContact AE to the shopping app, whatever it will be called (name suggestions also welcome in due time). Also, I already have a pretty clear vision about
Discuss the usability and feasibility of the selected software / it's source code and it's alternatives (as far as I remember there was the original iContact and some other derivate version).
[*]Create, discuss and review static prototypes of the interface (basically screenshots of each view).
[*]List the requirements to be implemented (or removed).
[*]Code in / remove code according the list from previous task.
[*]Create skin and graphics.
[*]Clean up rest of code, remove unnecessary parts of it (to make it more light).
[*]Test and review changes.
I can either take lead, perform or participate actively in the tasks that are listed green. I only need a competent C++ coder who can help and thinks this is a great idea.
The changes needed to the existing source code do not seem to be much at first glance, but of course as I cannot code in C++, I could be wrong. I just looked at the parts of code where to change the tabs and queries to storage files.
So there, got it off my chest. Any C++ gurus missing a simple, convenient grocery app?
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
aiiro said:
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
Click to expand...
Click to collapse
If I had money I to would offer some.
It's no wunder WinMo is falling behind no one wants to create apps even when offered a straight cash deal.
Amen to that. I was actually reading this and took a good hour of researching to see just how hard it might be and how time-consuming it might be. I would have loved to take this on...but alas, It would split me way too much. I am already working on my FFP_LS Pro 2.5 Improvements (Major Major improvements...I am practically re-writing the app), I am starting work on a game I plan to release (Its a rather popular game I have yet to find for WIndows Mobile), and I already volunteered to work on the Boggle Clone for WinMo ... so I am already pretty split as it is. heh...if I find free time, and nobody has taken this on, I will probably come back and make this my next project
Sorry though...I do hope some developer comes around to assist!
Thanks for Your support. I thought that I don't need to subscribe to my own threads in order to get a notification if a new post is made, but I was wrong. I certainly didn't get one for Your post. So, sorry for the late reply. I will subscribe to my own thread now
This is a short summary of some important general points for posting new ROM's.
It should be considered as an optional "add-on" to the general thread:
"Galaxy S I9000 Android Development **STICKY THREAD** Read here first!"
The number of man hours spent working and developing new custom ROMs are astronomical! So why then, is it that so few new ROMs are successful? Basically because of lack of information and poor public visibility/involvement of the developers themselves. It's just like in any other successful business, you have to make your product or service stand out from the rest. Either by making an amazing product or by being a great inspiration for others to follow. Here I will try to explain and list some fundamental ideas, in order to make your ROM better and more popular.
When a would be ROM flasher is looking around for a new ROM, he searches the web and the XDA-forums for threads, usually beginning with the text "[ROM]". Next he/she look at the FIRST page where the developer (and his/her team) is presenting the various features of their new design. What is presented there will often be a decision maker for whether or not someone wants to try it out.
There are a few things that consistently differs between "good" ROMs and "bad/poor" ROM's. These things are often and naturally related to the amount of information available around the ROM in question. Someone who have put down enough mind, sweat and hart into the production (cooking) of a ROM, would also like to share his/her effort in the best possible way, not minding writing a detailed and useful description about their product. The items found below are part of some of these things that do MAKE A DIFFERENCE.
- Primary Purpose:
Essentially a description why you want to provide this ROM and why you think it is needed. What are the main features and driving forces for providing this ROM?
- Ultimate Gaming Experience
- Super stability
- Super Compatibility
- Great Battery Duration
- Minimalistic User Interface (UI)
- Simple to use functionality
- Latest and coolest never seen before interface behavior
- Fully loaded with ultimate editions of absolutely everything
- Mobile Penetration Testing Platform
- or perhaps just for educational or experimental purposes etc...
- Up-to-date Maintenance:
That means an active developer (or group of) who are readily available to answer questions from users of all levels, new or advanced! Often that they should be inhumanly available at all times of the day & night!
- Up-to-date Firmware Release:
That means the the source of your ROM is preferably based on the latest, but publicly available code/firmware. Not on some hidden leaks or old hacked code. When I say "hidden leaks" here, I mean the kind where the origin of the code (compiled or not) cannot be verified or downloaded. (BMW doesn't make car/sales advertisements using 2 year old engines from unknown/secret sources!)
- Detailed CHANGE-LOG:
People want to know that what they flash on their phones, is as close as possible to what they would like to see and use. Also from a paranoia perspective most of us would like to know that it doesn't contain 3rd party or other strange applications that we will never use, or which will give us trouble when we want to add/update applications, at a later time. A description of the various applications is also very useful. Most people would wonder what the "DarkBotSendHelper.apk" is doing on a phone.
A change-log would ideally consist of a list with:
- Title: Change Date and the custom ROM Version the changes apply to
- Full application name
- Full application version
- Short application description
- Link to application source-code, if available
- Link to application on "Android Market"
- Reference to what hacks has been made, if any
- Reason for why the hack is needed
- Unresolved BUG-LOG:
A brief log of bugs and unresolved issues that affects the current release. It is hard to explain without cussing how annoying it is to flash a new ROM, just to find out that some WiFi issue has not yet been resolved, which was posted on page 456/1200! If people post bugs/issues, that cannot be immediately resolved, please add those issues to the BUG-LOG, on the front page.
- Screen Shots! Updated Screen Shots!
The importance of good screen shots can never be enough emphasized! Many ROMs are updated continuously and if the screen-shots doesn't match what the user installs, he's gonna go WTF!, and will start to peppering your support threads with questions about how to install this and that, and how to get the same themes you are using in those screenshots, or from another different ROM altogether! You wouldn't be able to sell a new BMW with a picture of an old Volvo, would you? So why do you think a ROM would be any different? Also include a brief caption about the essential feature(s) shown, for each picture.
- Detailed Installation Instructions
This hardly need more explanation apart for making sure you also say something about:
- WIPE/No-WIPE
- Bootloader Requirements
- Recommended Procedure
- Detailed Device Compatibility List
Yes, the same gross model name/number of a particular device, may very well have some minor variations that can render the device completely incompatible with software from it's apparent twin-brother. Or even certain Firmwares may not be compatible to slight manufacturing variation. See for example the "Samsung Galaxy S" with their sub-models GT-I9000(B/M/T), and to complicate things further, even within the same model there may be slight differences, like in the PCB of the USB-port of the SGS2 GT-I9100.
- Detailed Language Compatibility
What do people use their phones for? Communication! Sure, some use them as a game pad, but after all it is primarily a browsing and communication device. So if you can't use your primary languages with your device, it is useless! Although some network operators are only beginning to understand that most of the connected world is at least bi-lingual and often much more. Thus it is of essence that your phone's keyboard, screen-reader and web-browser can read, display and understand most characters and alphabets around. (I.e. I still fail to understand why it is virtually impossible to find a phone with Russian, English, Spanish and Norwegian keyboard layouts/character sets or at least let me select these my self!) In addition it is very confusing for a first-time ROM flasher to understand the need for all the various PDA/PHONE and CSC region settings, which are often modified and re-packaged for a well cooked ROM, and thus no longer adhere to the original regional code.
So when you cook your ROM, please provide as much information as possible regarding how the user can adapt their phone to his/her own languages. This information includes at least:
- What languages are available for basic operation (the operating system)
- What languages are available for the keyboard mappings
- What keyboard applications can use these languages (Swype, Samsung Keyboard etc.)
- Simple instructions how to include, use and set the phone languages
- List of Technical Terms and Definitions that describe the ROM
The world of mobile device development is packed by technical jargon and abbreviated terms. Many times they are also abbreviated and used in the wrong context, although some the community know what it means. Simplify your vocabulary and clearly define your terms and stay with community standard ones!
- General Presentation
Like any other business presentation, please skip the HUGE fonts in a zillion colors. Most of us are neither blind nor illiterate, but you may risk to come across as being both, with those type of fonts. Remember "KISS"? - Keep It Simple Stupid.
- SPELL CHECK!!
It's embarrassing and very annoying to read descriptions of how great, professional and how well maintained a particular ROM is, when the text is riddled with misspellings, wrong words and childish grammatical errors. Although most of us are very understanding that we are living in a multicultural and multilingual society, sometimes all I think about is, how a person who doesn't know how to spell check, could ever be able to cook a mobile phone ROM. Most text editors feature at least some basic spell checking, bloody hell, USE IT!
- CREDITS
Most of the Android development community is completely driven by voluntary and open source work. Make sure to include the correct credits to those persons who have contributed to the various info/hacks/software that you include in your ROM. Use a separate list for the credits, that include the name (handle) and how/what he/she did to contribute.
2 Good Examples:
http://forum.xda-developers.com/showthread.php?t=1350763
http://forum.xda-developers.com/showthread.php?t=1155776
Final Words:
It is very likely I have missed something here, or that you (as a developer or moderator) disagree on something I have written here, if so, please provide your constructive comments how I can improve this list and post.
In Great Expectations and Hope for Many New Amazing ROMs!
- E:V:A -
PS. This was posted in the "Developer Section" as it applies only to new ROM development threads, and I wouldn't consider this neither as "Q/A" nor "General". But if OP/MOD know of a better suited place, please just move it there...
Also I am not aware of a similar post to this one, even after searching XDA quite a lot. So if it already exists, it is not easy to find and should be reposted or stickied!
<Reserved>
@E:V:A
The only thing that I missed so far is a thread like yours.
Agree on all requirements of released software.
Sometimes I wonder how some "devs" priorities are stacked regarding quality control vs. early delivery on pay-per-download sites.
Not sure what is best place for this thread. Counting # of posts in General asking Q already answered in stickies, it's kind of accepted to skip reading what's there. :-\
Perhaps keep it alive as hottest thread here?
Tapatalked - There's a Thanks button somewhere
I like this
One thing you must add while promoting your ROM.. That is CREDITS.
Rahulrulez said:
I like this
One thing you must add while promoting your ROM.. That is CREDITS.
Click to expand...
Click to collapse
YES! Not giving credit where due is horrible, basically just forgetting all the hard work another individual has put in to the "feature" of your ROM. Also, this should probably be in general.
NOTE: European residency required as you will be working with our Germany-based dev team. English fluency required. German fluency is ideal but not required.
HOURS: Full time preferred, part time will also be considered.
JOB DESCRIPTION:
We are looking for an experienced Android developer to create a mobile version of our popular, cross-platform client which is primarily used for voice chat (VoIP). You will have the opportunity to look at sample code for an already existing version of this mobile app (former developer code) which utilizes a client lib for most of its operational, non-GUI features. Our intent, however, is for you to recreate this app with a more polished GUI look and feel, in addition to adding numerous missing features which will bring the app up to par with its iOS counterpart.
RESPONSIBILITIES:
- Review and understand our existing Windows/Mac/Linux client-server voice chat product, how it operates, and what sorts of features and functionality our existing users will expect for its Android version.
- Work with our development team to determine initial set of requirements, and contribute ideas for improving the Android app's usability and overall user experience.
- Write clean, modular code to implement the desired requirements with little supervision, and submit periodically to dev team for review via subversion.
- Engage in primary, core testing of the app although our development team will also conduct some testing and report bugs/issues back to you as well.
- Work with our support team to document and fix bugs with reasonable turnaround. You will need to setup, manage, and maintain your own bug-tracking software (eg - Mantis or similar). Our support team will require access to this system and assist in reporting bugs and issues for you to work on.
REQUIREMENTS:
- You must reside in Europe since you will be working with our Germany-based dev team.
- At least 4 years in mobile development experience, with 2 years in-depth experience in Android development.
- Demonstrated track record for developing and releasing Android applications. You will be asked for sample work and code.
- Strong understanding of Android OS, developing in ADS, interactive application development paradigms, memory management, network programming, audio playback and microphone hardware integration, concurrency and multi-threading.
DESIRED QUALITIES:
- Strong interpersonal and communication skills.
- Ability to work within a small collaborative team and have a great passion in producing quality products.
- Demonstrated experience in working with others to solve challenging technical problems related to performance and usability.
- Self-starter with the ability to assess and resolve complex technical problems.
COMPENSATION:
You will be compensated as follows:
- A fixed, one-time fee to be paid in 3 parts.
Part 1 to be paid once the developer agreement is signed.
Part 2 to be paid once the initial, documented and agreed upon set of requirements has been completed.
Part 3 to be paid upon release of the Android app to the public.
- Ongoing percentage-based rev share based on actual (net) income received from app sales.
- Details to be negotiated and determined prior to hire.
Applicants should apply by submitting their resume or inquiry to the Business Development department via TeamSpeak’s ticket system at
http://support.teamspeakusa.com
Thank you for your time and consideration.
I am working on a web service and thought it might be of interest to Windows 8 app developers out there, who might find the service useful and could even help testing it and offer advice on how to improve.
The product (codename Myelin, currently in alpha) brings powerful user feedback tools directly into your mobile apps. With just a couple of lines of code, you can integrate functionality that not only allows users to send comments directly to the dev, but also to track any replies and provide additional follow-up after the first submission. No private information (such as email address or account name) is ever shared, and no registration is required. It just works directly from the app.
Coming in the future are even more exciting features that make meaningful communication between the dev and the end user simpler and faster.
On the backend we have a feedback management portal that allows to monitor incoming feedback efficiently and manage any required follow-up in a bugtracking-like approach (think support tickets).
We have recently rolled out a client (== app plugin) for Windows 8 HTML apps, and would welcome devs willing to take it for a spin and give us feedback. BTW, XAML support is coming in the future; if you'd be interested, let me know and this work may move further up the priority list. XAML version for C#\VB Win8 apps is also available.
The service is currently free while it's in active development. While there are plans to eventually take it commercial, we will in any event be very accomodating to our early adopters.
You can read more at https://www.tfp0.com/s/windows8. If you're interested in learning more, reply here, PM, or just go ahead and sign up over at the website (we have plenty of spots available) to see what we have going there.
Below is a collage of various screens that the plugin introduces in the form of settings flyouts.
<= clickable
Since I've seen some offline interest in a XAML-based version, I wanted to note here that we did in fact roll out a version of the plugin for XAML.
In addition, both versions (HTML and XAML) are now available through NuGet as Timefork.DyneinXaml and Timefork.DyneinHtml .
We have been using Garage (garage.fueled.com) internally for the past few years, and are really excited to finally release it to the greater tech community.
It only takes a few lines of code to get started, and is completely free. The iOS SDK is publicly available to download on GitHub and should take less than 5 minutes to get up and running.
How it works:
Shake your phone to activate and capture what you’re looking at
Draw on the captured screenshot and add details about the issue
Record your screen to capture more complex issues
Send your bug directly to your Jira project
We know that there are many tools out there that do something similar, but we wanted to build something that was simple without too many extraneous features. Our criteria for a successful product was that it is easy to set up and could submit bugs in as few steps as possible. Testers should spend less time reporting and more time using the app.
We also wanted Garage to link directly to Jira, so that bugs are automatically sent to the project board with specs like the user’s device and build version. This makes it easier for developers to review issues, and product managers to prioritize accordingly.
As with all of our products, we will continue to iterate and improve. So, if you have any feedback or questions around implementation, please reach out!
Now, get out there and crush some bugs!