Suggestions for New Features
Manifold users are strongly encouraged to send in suggestions for new features or alterations in existing features. Every new Manifold release and update includes numerous additions that have been prompted by user suggestions.
This page provides tips for effective suggestions. For information on how to submit bug reports, please see the Bug Reports page. For information on getting tech support, please see the Support page for general information and the Contacting Tech Support page for details.
Ground Rules for Suggestions
Send email suggestions to firstname.lastname@example.org. Due to the volume of suggestions received, suggestions for new features will not usually receive a reply; however, all letters conforming to the rules below are noted and their suggestions are tallied with others received and compared to current internal product plans. There are several rules which apply:
- Do not send any suggestion or comment that you do not wish to become a part of the public domain, that is, freely usable by anyone without any control by you or compensation to you. All suggestions or ideas received by manifold.net enter the public domain and are not confidential. Do not send any information or communication to manifold.net that you want to remain your intellectual property. If you send it to manifold.net you are giving permission for that idea or suggestion to be used any way that manifold.net desires, including free publication onto the web for anyone else to use and also including sale to a third party, without any compensation to you or intellectual property claim by you. If you work for someone else, do not send any ideas, information or suggestions that do not belong to you or that are not already in the public domain.
- Suggestions for new features are generally prioritized by how many people request them. For example, if more people request enhancements in image editing than request enhancements in CAD-style drawing editing, the image editing tools will more likely appear sooner. However, suggestions made by just a single person could (and frequently will) appear in the very next update if the product planning team at manifold.net believes they will serve a large user base or if in some cases they are very easy to do and fit into an available engineering slot that would otherwise go unused.
- Not all suggestions will receive replies, but at times you may be contacted by manifold.net personnel to discuss your suggestion. If so, any such communications are not a guarantee that your suggestion will be implemented. Do not base your purchase decision of additional Manifold licenses on an expectation that a suggestion will be implemented as a feature.
- Any new features for Manifold are prioritized based on company plans and trends perceived from user suggestions sent in by email. Whether or not a new feature is implemented in a particular update or release depends upon its priority, the amount of time necessary to implement it and the availability of engineering slots within the development organization. Sometimes features of relatively low priority will be implemented ahead of high priority features because the low priority feature is easy to do and an engineering slot opens up in which that feature can be implemented.
- The product planning process excludes form letters, bulk letters, letters that were obviously not composed as a personal letter to sales and any letters cc'd to third parties.
- Please write in English and use a subject line that includes the words "Manifold" and "Suggestion" to assure your email will not accidentally be intercepted by spam filters enroute. Please use ordinary text format for your email, not HTML email, and write all of your suggestion in the ordinary text. Do not use attachments, as those are removed by security software before delivery.
- Please keep it technical. The mission is building a better GIS package for the Manifold user community and that has to do with specific technical features. Have faith that you will have persuasive influence by writing a detailed technical suggestion discussing performance, programmatic flexibility, workflow efficiency, Microsoft technologies, access to specific data sets or other purely objective technical matters. Non-technical comments, earnest flames, political rhetoric, etc., will only dilute the impact of a solid suggestion.
- For those suggestions that are contributed by only a few people the personal credibility and expertise of the suggester count for a lot. People who provide expert, complete and detailed suggestions win the credibility that makes it easier for product planners to commit more time to exploring the possible implementation of the suggestion, even if only one person has requested it.
Tips for Effective Suggestions
Some tips on how to make product suggestions that will influence the product as rapidly as you would like:
- Don't ask rhetorical questions. Suggestions should not assume replies so don't make the intake process try to guess when you are seriously asking a question and should be passed to tech support or when a question is just a rhetorical question to which you don't expect a reply.
- Do not combine tech support questions with suggestions. If you have business with tech support, take care of that in an email thread dedicated to that business. If you have a suggestion, take a moment to compose a standalone suggestion email so it can have maximum impact and will not be at risk of getting lost in the to and fro of a tech support transaction.
- Don't call a new feature you would like to see a "bugfix." For example, comments of the form "I've found a terrible bug in Manifold - it doesn't include a full-featured word processor like Microsoft Word" are a good way to lose credibility. If the product does not do something as it is documented, that's a "bug". If it does not include a feature or capability you would like to see, or if it is missing opportunities for additions here or there that greatly expand the usage of an existing feature, that's a new feature suggestion.
- Describe the new feature clearly and focus on specific features. The more detail you can provide about how it would work the better. General suggestions are appreciated but are not as likely to result in quick results. Example: "I'd like to see some more CAD editing tools" is too general to be very helpful. "I'd like to see move, scale, rotate, and flip commands like in 4.50" is very specific. A very general wish such as "I don't like reading documentation - make the product so it is obvious to me without reading anything" accomplishes nothing because it offers no specific suggestions at all.
- If enumerating a list of related capabilities, give some sense of your priorities. Example: "I'd like to see some more object construction commands. The most important in priority order are interactive Bezier curve drawing, the ability to draw a line perpendicular to another line or area boundary, and, if possible, a "centerline" line drawing tool that would constrain the drawing of a line to the mid-point of any two lines or area boundaries."
- Take advantage of your hands-on experience. Make suggestions in areas where your personal experience gives you knowledge about how something should be done and where you intend to personally use the requested feature. All suggestions are welcome, but suggestions of the form, "I don't have any experience in this and I wouldn't ever use it, but I think it would be cool if..." are not likely to be as effective as those informed by personal experience and personal needs.
- The product planning process values independent votes for similar features much more greatly than a cluster of votes promoted by an advocate. If many people independently throughout the world come to a particular conclusion and find a new feature important enough to write, that tells us it is something that is really important enough for many people independently to decide to suggest. In contrast, if someone makes a posting on a newsgroup that says "I think feature X should always have default setting Y... write to manifold if you agree" and we get a few dozen letters saying "I agree" with a copy of the posting, that tells us the default setting was really not a big enough deal for more than one person to feel strongly about, because no one else noticed it or cared until the issue was raised in a news group.
- The product planning process values personal emails. Letters that are cc'd to third parties are excluded. Send emails to email@example.com and not to the personal email accounts of any Manifold employees you may know. You may think you are lobbying the right person, but what actually happens is that employees will not vote for you by composing a letter on your behalf to firstname.lastname@example.org and so your advocacy will not be influential.
- The product planning process does not allow time for planners to do your research for you. For example, at times writers will send a brief summary of what they are interested in and will append a comment such as "For details, see the discussion in..." appending a URL to a discussion thread in some Internet forum. Product planners will not run down that URL and attempt to parse a discussion thread to try to figure out what, exactly, it is you are advocating. If the issue is not important enough for you to provide a crisp, detailed and standalone suggestion of what you want, then your comment will carry little weight and will have much less impact then an effectively advocated suggestion.
- If you are new to the product, don't jump to the assumption that something cannot be done and so a new feature is required. Research the documentation carefully. Take a moment to try out your ideas with your peers, perhaps by posting to the Georeference forum at http://georeference.org to see if you've missed something already in Manifold. If some preliminary exploration shows the idea is not already accomplished, please send it in. If your idea is already in Manifold but in your opinion too hard to find, let us know about that as well.
Suggestions for New Formats
We frequently receive requests to add a new format to Manifold System for import or export. We are always willing to consider adding new formats to Manifold. There are six main determinants as to whether a new format will be added:
- Is this a GIS format? People sometimes write asking for formats that have nothing at all to do with anything done in GIS. In other cases, people ask for technical notions that are not themselves formats but are something else. The classic examples are GML and XML, which are not themselves formats but are languages in which a wide variety of different formats can be created. In such cases, the specific format desired must be known.
- Do we have full and complete technical documentation on the format? If we have publicly available documentation (such as a URL) that completely defines the format it becomes much easier to consider. Note that an API that claims to read/write the format for you is not information on the format itself. Send such a URL or document to increase the chances your request will be implemented. Please do not send confidential information.
- Is the format a difficult one or an easy one to implement? Easy formats that are well-documented will almost always be added rapidly.
- Have we had requests for the format? If we have had very many customer requests it is more likely we will add a format even if it is difficult to implement. For an easy format that is well documented we have in the past added formats with only a single request.
- Are there samples available of data in that format? The more complex the format, the more samples will help to make sure the importer works correctly. If you send in a URL to a page that has plenty of samples the engineering team will know that any new importer can be tested. If there is no way to test the importer it is unlikely engineering resources will be committed.
- Is anyone actually using this format? Citing a significant collection of data that would be made available by this format answers the question. People and organizations invent new formats all the time that end up going nowhere. There is little chance a format will be implemented if no one actually uses it to any significant degree even if it has a theoretical following.
Therefore, the best way to get a new format added to Manifold System is to send Manifold a URL or other document that precisely describes the format in full and complete technical detail and that provides links to sample data that may be freely downloaded.
Users sometimes write "Can you add XyzGIS format? Their home page is www.xyzgis.com." This is not helpful because unless a very large number of requests for that format are received manifold.net staff will not be able to search the site for documents that might define the format. Users will also sometimes write suggesting a new format and pointing to an API that claims to provide an interface to the format. That's not helpful since such APIs almost always require agreement to terms and conditions. The cost of reviewing those on a legal basis is usually greater than simply implementing direct support for the format, and rarely are those terms acceptable to a competitive, commercial company like Manifold.
If you would like to advocate a new format, you increase your chances greatly by doing the detective work to find a solid technical description of the format and by providing some samples. Many of the formats in Manifold were added at the request of a single advocate who patiently located the required information and forwarded it to the Manifold team for implementation.
Requests for Broken Formats / Broken Standards
Manifold users will occasionally encounter files in formats that Manifold imports where the file does not accurately utilize the format. For example, there are many programs that can be used to write "shapefiles" which do not correctly write shapefile format, and there are images said to be in "GeoSPOT" format that are not written in accurate GeoSPOT format. Manifold.net will at times receive requests to alter the Manifold importers so they will read such pseudo-standard files.
There are two conflicting philosophies about staying true to a format definition. One philosophy says if something can be extracted from a file even though the format definition is not followed then do it. The other philosophy says that it is important to observe formats strictly and accurately as a protection against unknowingly importing damaged data. The first philosophy is often more convenient in the short term, but can lead to catastrophes in the long term. The second philosophy is more safe and professional, but can be less convenient in the short term.
Manifold tends to follow the second philosophy, of taking format definitions seriously. However, if there is a large body of data that systematically violates a format (for example, a large collection of data made available by a government), the manifold.net team is willing to bend the format definition a bit and allow such data. If you need such a relaxation of standards, the best way to argue your case is to provide a URL or other information that documents the existence of a large body of data in that "broken" format.
The above advice also applies to requests for nonstandard implementations of other standards. For example, a few GPS receivers say they use NMEA protocols when in fact they use a blend of standard NMEA with proprietary exceptions to NMEA. A request to support such "nonstandard standards" is a request to support something outside the standard and it will only be considered if there is significant usage that departs from NMEA in that way. For example, if a single, obscure GPS model departs from the NMEA standard there is little likelihood that the nonstandard implementation will be supported. On the other hand, if a major government organization buys a few million such GPS units then it is more likely that the nonstandard implementation will be supported.
Suggestions for New Projections
New projections are like new formats in that they are often easy to add if complete technical information is provided. The best way to get a new projection added to Manifold System is to send Manifold a URL or other document in English that precisely describes the projection in full and complete technical detail, including all formulae involved in defining the projection if the projection is not a simple parameterized variation on an existing projection. See the comments regarding suggestions for new formats as a guide.
Projections that are simple parameterized variations of existing projections are easily added to Manifold via customization and, if such a customized projection is indeed a standard projection in your part of the world, are candidates for addition to Manifold System as "built-in" projections. If you would like such a customized projection to be added as a "built-in" within Manifold, send your customization XML as well as technical references (so the manifold.net team can confirm your work) as part of the suggestion. If you do not have a customization XML but you know that the projection is a variation on an existing one, please send a technical reference URL that sets forth the projection.
Suggestions for New Styles
New styles (that is, new point icons, line styles, area styles) are like new formats in that they are often easy to add if a precise description of the style is provided. For example provision of a specific font, a specific page of examples and the like provide an exact idea of what you have in mind. Providing general comments such as "I'd like to see point styles like those supported by GraveyardManagerPlus Pro Edition" has zero impact as product planners really don't know what you want, will not do your research for you by acquiring a copy of that software package, and will not be able to compare whatever the software does to existing styles in Manifold to guess at which styles you would like to see augmented. A more effective suggestion would provide a clear example of various styles with a description of what they mean, how they are used and why that collection of styles would be useful to a particular constituency. Do not send any copyrighted material or any other material that is not in the public domain.
Frequently Asked Questions
Does sending a suggestion count as a support incident? Not unless it is embedded within a support request or a bug report to which a reply is requested. Example: "How do I thematically format a drawing using a text field in the sort order I desire? Please add a feature to specify sort order." This will be treated as a request for support and will require a support token.
What if my continued use of Manifold is dependent upon a new feature I have suggested? You should never acquire licenses based on anything other than the capabilities of the released product. Manifold is always subject to revision and alteration as manifold.net judges best. Although the product's evolution is guided mostly by user demands, keep in mind that other users may have different priorities that you do so that the evolution of the product may not include suggestions you have made.
How do I find out the status of a suggestion? Once a suggestion is made there is no way to tell the status until it appears in a new release. Manifold.net is grateful for all suggestions but is unable to provide reports of whether or not specific suggestions have been adopted and if so, when they will appear in the product.
How do I find out the release dates for new Manifold releases? In general, these are not published. Users participating in the Georeference forum at http://georeference.org, the main Internet forum for Manifold System users, will often hear rumors from factory personnel about general time frames in which new releases are to be expected; however, because manifold.net does not publish firm dates for new releases any such rumors should be treated as no more than broad predictions that are always subject to change.
Why are not suggestions on the GeoReference forum monitored? The main reason is that all Manifold users can write directly to email@example.com but only a small minority of Manifold users participate in Internet forums. By having one mechanism for intake, that of mail sent to sales, we can assure all users equal status in making suggestions and guiding the evolution of Manifold. This policy also reserves for the forum the freedom of having informal conversations and "thinking out loud" before sending in a suggestion. Quite a few suggestions for "new features" will turn out to be simply a lack of experience and not realizing those capabilities are already in the product. Testing out such ideas in the forum is a good way for new users to benefit from the knowledge of their more experienced colleagues.
Suppose I absolutely need a new feature - can I pay for it? Yes, although the cost is usually very significant, typically thousands of dollars to review a proposal and hundreds of thousands of dollars to implement it, depending on the level of custom engineering. Custom versions of Manifold System or scripts can be created with specific features that are required. Contact firstname.lastname@example.org with your requirements.
Please contact us at email@example.com. We would like you to be happy with your licensing of Manifold products, so please do not hesitate to ask any questions before placing an order.