Feature Scratchpad

This is a page to quickly record feature ideas that we might not want to lose but maybe aren't worth writing up as formal plans yet.

Let's designate user impact and implementation complexity on a scale of 1-5: 1 (trivial/cosmetic), 2 (minor), 3 (useful), 4 (major), 5 (fundamental). Things with high impact but low complexity would be the best "bang for the buck". Source is who came up with it, in case we want to ask them for clarification later.

Future Feature Ideas

Impact	Complexity	Description	Source
2	2	Expose setting to generate code with defaults set explicitly. Example: data-position="inline" on a header element. This might mainly be to facilitate learning. It could perhaps be an option just within the code view, and they would show up highlighted specially, and still not be included in the exported code.	Geoff
3	2	Support data-add-back-btn on header elements. More generally, support everything from http://jquerymobile.com/demos/1.0/docs/api/data-attributes.html	Max
3	1	Support data-rel="back" on button elements.	Geoff
4	2	Support image elements using <img> tag.	Max
4	4	Support generic blocks of HTML code. We should allow users to add blocks of custom HTML, with <div>, <h1>, <p>, <br>, etc. We need to carefully sanitize such HTML input though to make sure it can't break our user interface, much like how a wiki page allows a certain HTML subset to be used. This is a major effort to get right, unfortunately.	Max
4	2	Support images and links in the header element. We should allow users to put an image in the header instead of text, and be able to make the center image or text into a link. These could just be additional properties on the header element. Or we could have a new "Image Header" element.	Geoff
3	2-4	Support specifically setting a header button to the right-hand side. The problem here is mainly dealing with the fact that it's "just a button" but has a special property when and only when it's in a header. One solution would be to have a special "Header Button" element that has this property, but it's nicer if we can leave Button more generic. So perhaps a better option would be to have an extra property show up on the Button when it finds itself in a header. A related feature is allowing the user to actually drop the button on the right side of the header, and have it stay there and configure the added element with this "right" property set.	Geoff
4	3	Support adding and editing a CSS stylesheet file for the project. Rather than try to expose lots of individual CSS features maybe we should start with just letting the user add a CSS stylesheet, we include it for them in the generated code and in the preview, but not layout view, and let them edit it directly. Maybe we can detect if it has a parse error in the preview, and disable it w/ a warning, and also let the user toggle their CSS on and off there.	Geoff
2	2	Add an export dialog. When the export button is clicked, it would be nicer to go to a landing page/dialog that lets the user confirm what they're doing. This would also give us a place to add the decision to export just JSON or the full ZIP. I like how jQuery Mobile's Theme Roller handles their Download button, that's more natural than what we do now.	Geoff
2	2	Add trash can for drag-and-drop deletion. Currently the user adds widgets with drag-and-drop, but has to press the Delete key, or select a widget and go to Properties for the delete button. It might be better to have a trash can drop target appear somewhere. This should probably be considered by UX folks first.	Chao
2	1	Add background texture to the Preview tab. A good suggestion that the white background doesn't set the device off very well. Chao suggests a darker color, I'm thinking maybe some kind of texture, even just the grid from the layout view for now.	Chao
1	2	Add user preference for tabs vs. spaces or number of spaces (e.g. 2, 4, 8) for indentation. Even though we all know 4 spaces is correct. :)	Geoff
3	3	Support adding event handlers to widgets. The challenges here are how to write out the JavaScript code in a useful, extensible way. Also I think we should start with the most obviously useful handlers, like click handlers, not just add a huge laundry list immediately. Preferably we would study existing jQM app practices.	John
3	3	Restore cross-browser support. Determine the places where we've become dependent on Chrome/Chromium and come with cross-browser solutions to work on Firefox, IE, and beyond.	John
3	5	Support fully online operation, saving projects on the server. Requires user login and back end support. Probably requires UX input on how to explicitly save/sync.