Danger, Danger, Will Robinson!

Ok, so here's the thing.  I've heard horror stories of developers posting a "feature roadmap", only to receive a slew of 1-star reviews because they failed to meet the expectations that roadmap set.  I argued with myself a lot over whether I should post anything about features I intend on implementing and risk getting 1-star reviews, but in the end I decided that I would prefer to give customers more information rather than less. 

I am not committed to any of these features.

But I am committed to working on Flexile.

I beg you, don't buy Flexile based on Features you see listed.  I believe in a "fluid development cycle", which means I may postpone or even scrap a 'planned' feature based on user feedback or my own initiative.  I've done this several times already based on a "better idea" or feedback from someone.  For each feature I'll try to give some clue as to how likely (and maybe how soon) I intend to completing it.

If you want to get an idea of what features I've implemented so far (and how quickly I've implemented them), take a look at the Release Notes.  They should give you an idea of the progress I've made so far in Flexile. 

All that said, here's what I'd currently like to do with Flexile.  At the bottom of this page you'll see a form you can use to submit a new feature request.  Feel free.  I love getting feedback and new ideas excite me.  I may feel the idea isn't right for Flexile, but I will consider every idea.  Even if you do see an idea already listed you can still "throw-in" your support for a particular feature by using the contact form.  It'll help me get a better idea of what customers want.

Future Features

Likely to be done relatively soon

I plan on working on these in the immediate future.  However, there are quite a few so any particular one may not get done for a while or may get done soon, depending on the order I tackle them in.  This list isn't in any particular order.

  1. Multi-column (field) table sorting.  The back end (data management) aspect of this feature is already done.  I just need to create a control to take advantage of it.  The only reason it's not in Flexile now is that I really wanted to think through the UI and make sure it's easy and a pleasure to use. 
  2. Multi-Field Search & Saved Searches:  Similar to Multi-field sorting, most of the back end is done for this.  Of course (as usual) I've gotta figure out how to make an interface.  Sometimes this is more difficult than anything else...
  3. Table Aliases.  So this one's hard to explain.  It'll be a more advanced feature but I think it'll be a very powerful one once I get the details worked out.  The basic idea is to allow you to connect a record to a table (can be the same table) through an Alias.  In a sense, this allows a secondary categorization of Links, but it (possibly) will also allow multiple Links to the same record through the Aliases, though I may not allow that if doesn't make sense.  An example of this would be a table of word definitions.   You might want to connect to other words in the same table as "Antonyms" or "Synonyms" to clarify the meaning of the Link.  Table aliases would only be viewable through Links (you won't see the Aliases in the main table list.  I've only had the idea for this recently as a solution to a problem I have of being unable to determine exactly why I made a particular link.  No work has been done, but I'm pretty excited about it.  Still, doing this affects a lot of code so it may take a little while to complete.
  1. Rich Text Editing.  I struggled with this because I really wanted Flexile to have rich text when I released it.  But I also want to do it right...so it got cut from the initial release.  But this feature is definitely a priority.  Rich-text will be stored as a separate doc instead of placing it in the database itself (the database will hold a reference).  This will make rich-text docs e-mailable as long as I stick with a decent format.  I haven't decided yet on it, but I'm looking at XML/HTML and PDF.  I like the idea of using PDF but it would take a lot more work.  
  2. Global Search.  This won't be easy.  It could be easy but it would also (probably) be unbearably slow.  Per usual, if I do it I'll want to do it right.  I need to do a bit of research on search indexes and figure out design/implementation details, so this feature probably won't be in for a while.
  3. Crop Images (and maybe other editing).  I've never done image editing.  This sounds easy... but I won't know until I try.  UPDATE: This has been partially implemented.  I learned that Apple's selection process will allow users to crop a photo before selection, so I enabled this.  However, the control itself still doesn't crop photos after the selection process.  Also, I may include the option to decrease a photo's resolution in order to save space.
  4. Advance Audio Editing.  Ability to select, delete and rearrange audio segments;  adjust audio properties (like gain).  Maybe others.  I've done a little audio processing, but the most difficult part of this will be the interface.  It'll probably be done a bit later.
  5. Reports/Printing.  It'll take a lot of work but I recognize that being able to graph and print information is important to many people.  Additionally, since the data structure is arbitrary (user-defined) I essentially have to create an in-app report writer.  It is something I plan on doing, but it'll probably take a little while to get done, and I expect the first implementations will be fairly simple. 
  6. Graphing.  Graphing is a fairly big and complicated process... one that I find quite interesting.  I'll be honest here and tell you that while there are several 3rd-party options for developing this feature, I will most likely opt to build my own.  The first reason is selfish: I want the experience and I'll enjoy the challenge.  The second reason is more practical: I've never regretted making my own code, while I have often regretted using someone else's.  When it's my own code, I can make it do what I want.  Too often I've run into restrictions/problems with a 3rd-party framework that caused me to abandon it, wasting hours (sometimes days) of work.
  7. External File Attachments.  I'm not sure exactly how I would implement this.  I could create a separate field for each type (like I already to for images and audio) but I it may be better to have a generic "External File" field type and provide dynamic viewing support for certain file types.
  8. Custom Calendar View.  Display records in a calendar.
  9. Table Indexes.  Display the side-bar index that scrolling lists sometimes implement to help you 'jump' to a particular section.
  10. Copy/Duplicate Tables.  To be fair, once I've completed "export/import" you could export your data and then import it back into another table.  This feature would then be more of a convenience, but a worth while one. 
  11. Central Image Management.  At the moment, separate images are kept for each record.  If you want two different records to use the same image, you can't.  Flexile keeps a duplicate of each image.  To be fair, both records to a third record that contains the image would suffice just fine but a central place to manage images might be nice.
  12. Link Badges/ Heat Map.  One interesting suggestion given to me is to add a badge count indicating the number of links each record has in the record list table.  While this sounds simple enough, the problem lies in that I don't retrieve links from the database until you open the record.  This greatly speeds record retrieval but also makes it impossible for me to know how many links a record has until you open it.  I like this idea though, so I'm not opposed to looking into alternative methods of Link detection.
  13. Interactive Link Graph.  This one would be a lot (seriously, a lot) of work but I think would add a whole new level to Flexile's usefulness.  The idea here is to generate an interactive graph displaying all of a record's links, grouped to each table.  Tapping on a Link would shift the graph to that record dynamically.  Tapping on an already selected Record would open that record for viewing.  Probably the hardest part of developing this is creating a layout engine for the graph objects.  
  14. Templates.  Flexile can theoretically replace a lot of smaller, single-topic apps.  However, not everyone wants to design a database.  So I'd like to create very customized templates designed around specific "topics", like a "Contact Manager", "Password Manager", "Task Manager", etc.
  15. Field Dependencies. This would allow you to set a field as dependent on another field for data entry.  This would allow you to select other field(s) that are required to have data in order to enter data into this field.  Ideally, this field would only be visible (...maybe?) when the other fields have been filled out. 
  16. Multi-set Pick Lists.  This would be a control similar to the standard "Pick List" control, except that it would allow for multiple value sets.  As an example, you could use a multi-set pick list to keep track of cars: Year -> Make -> Model.  Each sub-set ("Make" is a subset of "Year") can have an independent set of values for each item in it's master set.  This would be a complicated, advanced control and I'm not entirely certain it's necessary.... or even desirable.  It would be much better if I could make it easy to accomplish the same sort of thing using Tables and Links.  If I can use Tables and Links, this control might not ever come to be (or need to be).
  17. Link Constraints.  Link constraints would limit or require certain conditions be met for Linked Records before you can save.  Examples of this would be: Must have < 1, 2, 3... > links to <table>, can only have < 1, 2, 3...> links to a table.  Sum of <table-field> links cannot exceed (or must be) to <field value, constant value>.  This would provide additional structure and provide checks and balances to Links. 

Long Term Goals

These are goals I want to do but are on a more long-term track.  Some of these might be done sooner if I get enough customer support (requests) for them.  

  1. Mac App.  Of course, a lot of the code I use in Flexile iOS can be moved directly over to the Mac.  However, I do not want to simply 'replicate' the iOS interface on the Mac.  Instead I'll be re-thinking the Flexile experience on the Mac, so while it will be Flexile it will also be different.
  2. Web Cloud Sync.  This will keep the databases in sync between all your Flexile devices.  This has always been a goal and will continue to be.  I may even start working on it relatively soon.  Just don't expect it to be done relatively soon... from every account I've heard syncing databases is not easy or trivial (even Apple struggles with it).  Of course, there's a possibility that my extraordinary genius will tackle the problem in short order but I personally wouldn't bet that direction.  I will say that syncing will be subscription based and is part of my long term plan to make money... so the motivation is definitely there.
  3. Web Access.  Obviously I'll have to complete the "Cloud Syncing" feature before this one, but I think giving access to your database from any device with a browser would be very valuable.  Kind of like the Mac App, I will be re-thinking the Flexile experience on the web.  So a lot of work will go into this before release.

Wish List

This is a list of "wouldn't it be nice" features.  I'm not planning for any of them but it doesn't mean they won't get done.  It just means most everything else will get priority.

  1. Multi-platform Apps.  Eventually I'd like Flexile to be available on Android and Windows devices.  But there are only 24 hours in a day...
  2. 3D Interface.  Ok, I really like this idea.  I think the "Links" between records would make for a great 3D interface.  (I don't mean 3D with glasses, just displaying in the information in a 3D space).  This would allow you to actually see the links between records and follow them, graphically displaying your data dynamically.  
  3. Social Integration.  I think it would be nice to be able to pull/link-to feed data from Facebook / Twitter enabling you to link records to a Post or Tweet.
  4. Remote Image Access.  This would allow you to store images on another service (like Flickr or Photobucket) and download them dynamically when you want to look at it.  This sounds good but I'm not convinced it's a good idea.  It has the potential to add too much complexity in my code, especially when I implement cloud syncing.  I start to shudder thinking about keeping track of Logins, locations, and where images are coming from.  Plus, doing all this and keeping the interface simple might be impossible.  Still, I haven't completely shut-down the idea.   

Want a feature you don't see or add support to a feature?  Let me know!

Name *
Name