Testing

I was starting to get a bit scrambled with all the code I was writing, and I knew that there were probably a thousand bugs in the code that I had already written, so I decided to take a break and test what I had written so far.  I made a simple interface, and started diving into the bugs.  I'm very glad I decided to do this early on because I found even more differences between SQLite and MySQL, which required some rewriting.

I am only testing the general idea types at the moment.  I haven't tested the actual idea instances yet.  In fact, I haven't even started testing the idea types' columns yet.  I'm just touching the surface.  There's a surprising amount of testing to be done on every level.  However, I'm almost ready to start testing the columns.  I only have one more thing to test, and it has to do with inheritance.  Alot of work went into the code behind switching an idea type's inherited type.

There are three different scenarios I have to account for.  First, when the new inherited type is completely unrelated to the former inherited type.  Second, when the old and new inherited types share a common ancestor (I have to make sure all data that the two share is preserved).  Third, when the new inherited type is the type's descendant (which basically means that the type will inherit itself).  The first two are done for now, but the third has yet to be tested.  Originally, I wasn't going to allow the user to do the third one because it sounded like a mistake.  However, I found a way to make it work.

If you think of inheritance like a hierarchy, I'll remove the type from its old spot and fill the gap by tying its descendants to its ancestors.  After that, I'll stick it in its new spot.  That way, there won't be any circular inheritance.  This was a bit tricky to implement.  My brain was a bit fried for a few days, so it took me a while to pin down the best method, but it's written.  All I need to do now is test it.

I'm excited to finish testing this last step because that means I can move on to the columns.  Once they're mostly done, I'll likely move on to writing the link data that I mentioned in my last post.  It's a bit daunting, but I can't wait until it's done and working.  I've put alot of hours into this iteration of Idea and I'm ready for the gears to start turning.

In case you're curious, this is what my little test form looks like so far:

No, this is most definitely not what Idea will look like in the end!  This is strictly for testing.  Idea is only a library of code right now, and this form lets me play with the library.  After I feel that the library is complete enough, I'll start coding the real interface...hopefully.  I still have to figure out the best way to do it.  That's where I'm still a bit stumped.  Heck, I might go through multiple iterations of it before it's done, and that's fine.  It will be alot easier with the foundation already completed.

Thanks for reading!
clevceo

Link Data

I've been thinking about something lately.  It's about the links between ideas.  For example, linking a character to a scene.  What if you wanted to attach a caption to that link?  For example, you could say what role the character plays in the scene.  Of course, you could put this in the scene or character ideas themselves, but the scene has alot of characters, and each character is in alot of scenes, so it could get messy.  If I could attach that caption to the link itself, then that would resolve the issue.  When expanding the link to look at the character, it could show the caption as well.  I'm not sure how I would display that in the UI, but it could be extremely useful.

As I thought this through, I thought "What if they wanted to attach some other kind of data to it, like a number or a picture?"  I realized that I can't restrict it to a simple caption.  I have to allow the user to decide what data to attach to each link, if any.  Each link will be a miniature idea, containing a list of fields.  However, this introduces some new complexity.  I might have to set some boundaries for it.  For example, the link ideas can't inherit.  And "maybe" they can't link to other ideas (since it's already a link anyway).  The rules are likely to evolve over time.  Hopefully this doesn't get too out of hand.  I don't want to bite off more than I can chew.

This makes Idea a bit more daunting, but I think it will be a really nice feature.  It will help keep things organized.  Anyway, thanks for reading!

clevceo

User Interface

I'm still working on the inheritance code.  It's alot of work and my free time is sparse.  However, in between coding sessions, I've been thinking about what I will build on top of the base Idea library.  Basically, all I'm working on now is the base file storage for the base idea structure.  So far, I haven't even touched the UI.  Thinking about it is a bit stressful.  Since there are no precedents, I'm not exactly sure how to do it.  However, I have a few ideas.

There are two specific ways I want the user to be able to interact with ideas so far.  First, they will have a basic drawing board.  They can drag and drop ideas onto it, arrange them how they please and edit them while they're sitting there on the drawing board.  This is the most basic UI idea I have.  In the finished product, this feature might evolve drastically or even be tossed, but I think it's a good starting point.

Second, I want the user to be able to create his/her own interface for the ideas.  This will be similar to Microsoft Access forms.  I think this can be very handy if done right.  Then again, I haven't tried it out, so it might backfire.  But all ideas are good ideas until proven bad, so I'll give it a shot.

The drawing board will be my first project, just so I have a playground to test things out.  It will likely change alot over time.  My ideas for the UI aren't nearly as solid as the idea structure.  At the base level, a saved drawing board will store which ideas are in it and their locations.

However, there are a ton of other features I've thought of as well.  Here are a few random ones:

• Hiding certain fields in an idea.
• Hovering over a minimized list field will show a small sub-menu that allows them to either expand the list within the idea or show the linked ideas to the side with lines connecting them.  Maybe rather than a typical menu, the choices would be visual.  In other words, to the side would be a faint image of lines branching out to squares and below it would be a faint image of a list of idea names.  They need only hover over one and click.
• Operations on multiple ideas at once.  For example, if the user selects a group of "scene" ideas, then he can have them all show the "character" ideas linked to them.
• Automated arranging.  Somehow, I'd like to allow the user to make the layout of the drawing board automated.  In other words, when the user expands a list of ideas next to a parent idea, rather than just placing them on top of other ideas, arrange them in a visually pleasing way...somehow.  I'll have to research that.  The biggest difficulty would be dealing with all the "link" lines running around.  Maybe I'd have them go "around" other ideas rather than keep them as straight lines.  We'll see.
• Masks.  A user can create a "mask" which is a preset view for an idea type.  In the mask, the user will set how the idea will be displayed on the drawing board.  For example, he/she can choose which fields will be displayed, which ones are read-only, etc.  The user can set certain drawing boards to only show certain ideas with their masks or the user can open individual ideas with certain masks.

That's just a few.  I need to keep track of them all.  I'm excited about it, but it's definitely daunting.  While I hope to be done iterating the foundation of the software, it's time to move on to the UI.  I've made so many iterations of the foundation, but every iteration of the UI (there have only been a couple that were usable) has so far only been basic.  I only made them so I could test the software.  This time, I'll make additions to the foundation and evolve it slowly, but I will not start over on it.  SQLite makes it easy to keep the changes small.  But the UI will go through huge changes over time.

I really want to keep it fairly experimental for a while.  Idea is a new animal.  No one has done it before.  I have no precedent, so I don't want to try to make it work like existing software that I've already used.  I'll borrow ideas, of course, but I'll also make up my own.

If you can tell, I'm excited about Idea.  I want to get past the foundation so I can start playing with UI.  It will be a little longer before I can, but I'll keep trucking along.  If you like my ideas or if you have one of your own, please let me know.

Thanks for reading,

clevceo

Inheritance

Lately, I've been implementing all the database interaction.  Using a database is really an ideal way for Idea to work.  However, there are a few things that databases don't necessarily do well that are important to Idea.  The most prominent is inheritance, which I talked about in my last post.

Inheritance is an important concept in object-oriented programming, but it's non-existent in relational databases.  Therefore, I had to come up with a way to imitate it in a database.  I can tell you, it wasn't easy.

Sometimes things just click and I gain momentum, and I never seem to hit any ruts.  Well, I was that way in my first few iterations of Idea, but I'm not that way now.  It's mostly because my current version requires alot of work on the foundation before I can ever even test the thing. So far, I've had to hold everything in my head, and I'm doing something that hasn't really been done before, so I don't really have any precedents.  The best way to do things isn't very obvious.

Before, I just jury-rigged everything, but now I'm focused on quality and performance.  This time, it's not just a fun experiment.  This time, I really want to take it somewhere.

Thus, I was determined to find the best way to implement inheritance.  I'll be honest, the first way I thought up seemed really nice at first, but then I realized that it opened a huge can of worms when changing existing idea types' settings.  Then I came up with my current method, which at times seems a little tedious, but it utilizes the nifty perks of relational databases better, which actually make things sooo much easier in the end.  For example, if you were to change an existing idea type's inherited type, the old way would have been ridiculously hard and impractical.  The new way, while still difficult, makes it infinitely easier.

I'm actually a bit proud of my inheritance code.  However, it's probably riddled with bugs.  I haven't tested anything yet.  I'm excited to get to that point.  However, I know I'll spend a couple days just ironing out bugs.  But that's fine with me.

Thanks for reading!

clevceo