This is a quick first stab at an FAQ. We will make it a better interface soon.
The IxF is a framework for getting your web application project up and running fast. The IxF is made up of three main components. Style, Plugins, Glue.
The IxF comes with a great looking style out of the box. Different components look like they were made to work together. Hopefully it is everything you need right out of the box, but you are of course able to customize it if needed. We hope you don't need to customize it too much, as that defeats the purpose of it saving you time.
If you just want a different color from the black based stuff around the sides, give our themeroller a try.
The IxF comes stocked with a number of plugins that we feel will make your webapp shine. Here is the full list of available plugins. You of course can add anything you need that is specific to your project.
The IxF comes with some extra code to help you get up and running faster, that has come to be known as the "Glue" (you know, holds it all together). Instead of needing to go to each plugins documentation to learn how to use it, we expose the most common settings via an API that we feel is much easier to learn. We by no means are trying to cover all potential situations. Just the things we think will come up the most often. If you've heard of the 80/20 rule, we try to take care of the 80 (the simple stuff that there is a lot of, that will take 20% of your time) to give you more time to focus on the 20 (the difficult stuff that will take 80% of your time).
Now we know that these common settings will not fit uncommon situations. Every plugin is included in it's entirety. If the glue doesn't do what you need, you can run an instance of the plugin that you can completely control. Nothing in the IxF runs without you telling it to via specific classes as specified in the documentation.
There is no reason to reinvent the wheel (datatable, forms, etc) over and over for each new project. The IxF takes care of the things you see all the time in web apps. This allows you the time to come up with other cool stuff beyond what the IxF provides. Hopefully the IxF got you up and running so fast (both designers and developers) that now you have more time to work on the harder problems that are specific to your application.
A few more benefits
Designers and developers of all skill levels. Oh and lets not forget our users.
We have a wide range of skillsets in both designers and developers. From those who are just stepping into this new world of JavaScript, to experts who have done it for years. Anyone along that continuum can benefit from the IxF. For novices, they may not understand the complexities of a given plugin, so the IxF hopefully makes it easy to implement without needing to know those complexities. Even if experts can understand the complexities of a given plugin, that doesn't mean they need to spend time and brain cells doing so. Their expertise can be put to better use solving real problems, not learning how to configure a basic plugin.
Designers get the benefit of not needing to design yet another datatable (or other components). They can spend time coming up with stuff outside the normal box of what a webapp is. Focus on fixing problems specific to the project, not reinventing the wheel.
Prototyping is very easy and simple to learn. You can have an instance of the IxF duplicated and ready to be modified within minutes. No need to spend hours or days laying the fundamentals of a project.
The IxF is not just a prototyping tool. It's ready for production. The exact same things that make the IxF fast to prototype with also make it fast to develop with.
Our users benefit from consistency across all apps that use the IxF. Widgets look and act the same, so there is less learning curve.
Users also get a more robust product that hopefully solves their problems better. This is facilitated by the IxF taking care of the basics, allowing designers and developers to spend more time on the tough problems.
Please see our browser support page for details.
First and foremost know that PHP is NOT required to use the IxF.
Even this demo site is quite complex, and we would be foolish not to use global include files and a few if statements to make maintenance easier for us. PHP is free, relatively simple, easy to install, doesn't require compiling, etc, etc. So we went with it.
The general functionality of the IxF is agnostic of any backend. The IxF dictates some HTML structure that should be used, which is then leveraged via CSS and JS. Really the CSS and JS is where the large majority of the IxF magic happens. The IxF has been successfully used on stack, Java, .Net, Rails, PHP and GWT implementations so far.
There is an amazing effort going in to jQuery Mobile. They have a fantastic list of supported browsers and is being built by some of the smartest minds in the industry. We would be foolish to try to reinvent what they are already doing and giving away for free.
jQuery Mobile is still in it's early stages of development. We are waiting for it to stabilize (coming very soon) before we seriously dig into it. It is highly likely that we will just suggest using it straight out of the box. There will not be a 1-to-1 match up for mobile features to desktop features. But we will try to provide guidance on how to make both work together with as much consistency as possible.
Then don't. Nothing in the IxF is forced down your throat. You have to use certain classes to make the IxF start the configuration process for you. If you want to roll your own take on tabs, autocomplete, etc. just use a unique class and you are good to go. Similarly you don't have to use the included components at all. You can bring in your own autocomplete if you really want.
Now the style is a bit of a different situation. Even if you roll your own autocomplete, tabs, datepicker, etc. it will still have the standard IxF look and feel. It just won't be configured using the IxF defaults.
This is something we debate constantly. There are a few tradeoffs here.
The plusses of modularizing everything is easily changing out a given module, and users only download exactly what they need (not the full package with parts the site may not actually use).
The negatives are needing to track all those modules to make sure you have what you need. Providing the option to easily change something out can promote inconsistency from app to app. A lot of work has been put into making the current components work well together and be easy to implement. Much of that would be lost.
Naturally the plusses and minuses are the opposite of what are listed for the modules.
Plusses are you don't have to track down what you need, everything you need is included and ready to go. Users download one larger file at the start of their session, and they are done. All other pages come up fast because the files are cached (if you are using a CDN). If you are using a CDN, you get the benefit of the herd, in that if your user has visited another site using the IxF (and is pointing to the same CDN files), they likely already have the files needed for your site as well. Then there is no download time. If every site had their own specific conglomeration of components, we could never benefit from pointing to the same files.
We get consistency because we are all using the same components and they will work and act the same from site to site. You get the IxF configuration options which help you get up and running faster.
Negatives are you get the larger file that users have to download. You can't change things out if the IxF's component doesn't do exactly what you want.