List of Useful Widgets

Details about the Widget feature.

Widgets ideas goes to infinitum since for every application you need a few specialized widgets. However, having a strong base will definitively help in getting small applications done without the need to re-implement widgets everytime.

The following is a list based on Qt widgets (since I consider that Qt works quite well for many apps.):

Box -- a box used to group other widgets (should support a grid like feature -- this may be what we call the layout though)
Button -- a widget that you can click to generate an action; it should be possible to set the button to a set of images (clicked, focused, hovered, etc.) and to mark which button is the default (i.e. Enter activates that default button)
CheckBox -- a widget displaying one checkbox (on/off button); we may want to add support for a 3-state button, although I rarely have had such need (using Radios is generally better in this case.)
CheckBoxes -- a list of checkboxes to make it easy to show many flags without having to create one entry per flag; also, the display can be different: an array of checkboxes would have one title/description whereas multiple CheckBox widgets would each have their own title and description; the display of checkboxes must be horizontal, vertical or in a grid... so internally this is a box with a set of lone CheckBox button
ComboBox -- in HTML this is called a Select, it should support forcing the user to make a selection and showing several different lists with titles (actually, reprogramming the drop-down would be best if we want to really allow a specific look and feel for a website, when the system combobox would not match well.)
ColorSelector -- a widget to select a 24bit color
Date -- a widget to edit a date, either with or without a popup calendar
Dial -- a way to select a number on a dial like shape (like old rotary phones)
Dialog -- like the MessageBox and lightbox to display images, we want a dead easy way to open dialogs to display data and forms; dialogs may darken everything else or not; (see also Window)
Document -- all widgets must be created in a document widget; the document includes the HTML header information (i.e. title, links, meta data, etc.); of course, many of the options available in the Document are automatically handled by lower level plug-ins; for example, the addition of JavaScript and CSS files is not done by directly hitting the Document, this is done by sending a signal and those low level plug-ins can react and do the appropriate assignment (or detect potential conflicts and thus ignore the add); also some entries are forced (i.e. UTF-8 encoding, title) and some entries may be ignored (i.e. base specification)
Embed -- a widget used to embed something not directly supported by HTML such as audio and video
Fieldset -- a field set used to logically group a set of widgets; include a collapsible capability (although really that should be part of the box I think); see also Group
FileSelector -- a widget that let you select a set of files to upload (attachments, inline image or embedded content)
FocusFrame -- a frame used to display the focus of whatever is inside the widget (most certainly requires JavaScript!)
FocusHelp -- an object that adds help to all the items that can be focused (as we've done in the Order Made registration)
Frame -- a widget that draws borders contrary to the box we should limit what is shown inside to one item
Group -- a virtual or transparent grouping mechanism (i.e. an object that allows you to logically group items together without having to generate extraneous HTML code); see also the Fieldset widget which creates an actual fieldset around items (and the Box & Frame); note: since a group is virtual it cannot offer dynamic funtionality, once the HTML is output, it has no meaning at all (i.e. it is not accessible in JavaScript!)
HelpBox -- defines help for an input widget: line edit, check boxes, radios, buttons... (although I guess all widgets could accept a help box, there's probably no point); the help offers a common way to display help in a form (i.e. open up in a pop-up with the help text; opens a dropdown just below the currently edited widget; shows only when a help button is clicked; etc.); if a link is created, mark it with rel="help"
Hidden -- a hidden widget used to hold some data, quite often a state that will be used when the POST is received; however, it is generally wiser to make use of the form session and save your hidden values there (so it stays on the server); however, at times there are necessary hidden value that change while the user fills the form (i.e. in a list of items to be sorted using a drag and drop feature, you'd have information about the position; that would generally be saved in a hidden variable since the user does not otherwise see that position information); in regard to hidden widgets, we also want to support scripts used to gather statistics and those are also hidden "widgets"
IFrame -- an IFRAME tag; define a size, whether we want sliderbars and a URL for the contents
Image -- a way to display an image, although we could use the text area and add an image tag, we want to have a way to display images without having to do too much work (i.e. give path to image, voilà!)
ImageEdit -- a widget to edit images: position, resize, crop, flip, 90° rotations (other feature that we can do in JavaScript... but avoid hitting the server! although I don't think JS can do a flip or any rotation.)
Label -- one line of text (no wrap, maybe clipping on overflow though); should include a display format so when doing a setText() to that label the text gets formatted in some way (i.e. numbers could be converted to images so they show up as LCD digits or some other cool number display.)
LineEdit -- a one line of text the user can use to enter text; this needs support for "strong" validation (i.e. numbers only, birth date, social security number, specific postal code, etc.) using a regular expression which can constrain the total length of the entry and whether it is required; and of course, a way to offer a multi-line or text edit; plus the possibility to use a WYSIWYG editor; there needs to be a way to put a label inside the line edit box (like we have for the user login, etc.); and a very easy way to offer an auto-complete feature (especially, automatically offer the last X entries without having to hit the server... simple but most certainly effective!); although we can specify the graphical (pixel) size using CSS, we also want to support a width, height, and maximum length (if height != 1, then multi-line text!)
List -- the combobox when shown as a list... this allows for multiple selections
Menu -- ways to display a menu: simple list, drop-down, open/close sub-list of items, etc.
Password -- a widget that displays a LineEdit for entering a password; if we reprogram this one, we can avoid displaying the number of letters typed; emit a beep on each letter entered, etc.; can include a "Please confirm password" and JavaScript code to check the password strength (preventing submission if not strong enough.)
ProgressBar -- a slider like bar that shows progress of different features such as uploading a file, sending emails, and updating a large number of pages
RadioButtons -- a set of radio buttons; there is no point in having one radio button by itself, so we only offer a set (althoug internally we have to support one radio button to be able to create a grid of them); you must define a list of choices the user can make and whether to display it horizontally, vertically or as a grid
Screen -- represents the screen (i.e. what's visible)
ScrollArea -- a box which size doesn't change and contents can be scrolled using default system scrolls
Separator -- a bar used to separate different things on the screen, a bit like an <hr> tag in a text; with a drag and drop capability, we could offer the user a way to resize areas using the separator
Session -- the session widget is a hidden widget with a session number used to verify that the form was indeed created by Snap! (so the POST is expected)
SizeGrip -- a corner or border offered on windows to resize them
Slider -- a way to select a value or position something using a slider; for an area, we'll always use the system slider so it remains efficient
Spinbox -- a +/- on a number line edit used to increase/decrease the value in the line edit; precision should be specified and we should support floating point numbers
Splashscreen -- a way to display an animation or at least an image in front of everything else while loading (this is dangerous if no JS is available?)
StackedWidgets -- to create a stack of widgets; this could be used by the TabbedForms and Wizard, but the point here is more for a visual stack effect where you can later click on a semi-window window
StatusBar -- a bar generally displayed at the bottom of the screen or of a window that shows the user the current status; in a "Browser Mode" we can also make use of the browser status bar (but that doesn't work well on many browser); this should be versatile enough for us to display a banner ad type of a thing in the status bar with alpha, etc.)
Tab -- a tab widget used by tabbed forms
TabbedForms -- a way to have multiple forms selected using tabs; need to support horizontal and vertical tabs (note that it says "formS" but we actually have a single form so the Submit button will send all the "formS" data at once. This means the tabbing between the forms is instantaneous.)
Table -- this is a can of worms, of course... we want to support tables, but there are so many ways to support them that it will be complicated to do everything HTML offers; we may want to offer several levels/degree of complexity using different objects deriving from the base Table object (TBD)
Text -- a multiline widget of text, similar to the Label, but does not force a one line and clipping; could make use of a sliderbar if the area is too small though
Time -- a widget to enter a time in 12 or 24 format with or without seconds
Toolbar -- a movable bar to display a menu, if like current Snap, would include tabs, and a Close button
Window -- a window would be a dialog with a standard title bar that we can use to drag the window, to maximize it, minimize it, etc.
Wizard -- a set of forms that are shown using a Next / Previous mechanism; the set of forms could be similar to the TabbedForms (we probably want to reuse the same object that lists all the "forms" we want to walk through); note that all the "forms" are part of one single large form as far as the server is concerned (i.e. the user goes through all the pages and at the end submits to the server -- although we may still have an auto-save)
Wrapper -- a widget used to wrap another in a given HTML tag (I think that the box will be enough, put here just as a reminder to see whether we need such a feature.)

Like Qt, we should program those widgets with margins, padding, borders, auto-resize to parent widget, etc. although, of course, all of those features are already available in HTML/CSS so it's easy enough.

Common Attributes

All the widgets are HTML objects (DOM) so they all accept the same basic set of parameters (especially in HTML 5.)

We want to have a base class that offers the following as attributes that all the widgets will share:

Label
Help (this is defined using the HelpBox)
Identifier (the widget name)
- Must be a valid JavaScript variable name
- Used as anchors
- Used for arrangement, sorting (before A, after B...)
Classes (map, value == key)
Styles (map)
- Status (enabled, disabled, hidden, etc.)
- Position
- Size
- Margin
- Padding
- Text Color
- Background
- etc.
Event Handlers (for those we need to use jQuery...)
Access Key
Tab Stop (computes the tab index)
Language (especially if a box is allowed to show another content that was not yet translated!)
Context Menu (menu that appears on a right mouse click)
Draggable
Drop Zone

By making the Identifier mandatory, we can offer an easy way to sort all the items (i.e. before Blah, after Foo...)

3rd Party Widgets

Many of the features we want to support will be HTML code that comes from 3rd party providers. For example, the Google +1 widget comes from Google, the AddThis widget comes from AddThis, Facebook offers many widgets too, etc.

All of these features should be widgets so any module can build a page with them (although they would be plug-ins in their own right, we need a "repositoty" or factory of Widgets that anyone can contribute to.)

The following are the widgets we're currently using or have used on our websites:

AddThis
ShareThis
Google +1
Facebook Like, LikeBox, Comments
Google Analytics
Feedburner (the public RSS link changes)
CKEditor and other 3rd party WYSIWYG editors
Embeded data (YouTube video)

Sorting Widgets

In the end, on the screen, the widgets must appear in the right order.

When a form is built using many plug-ins, changes are you won't be able to define all the widgets in the exact order you'd want to create them. I.e. the module that owns the form creates it; then it signals other modules that can then modify the form as required... by adding new widgets, for example. In that case, a button should be along the other buttons. If adding a capability to the title (i.e. an auto-URL feature) then you probably want that feature to be attached next to the title. This would not be possible without a way to find the title and add your widget just before/after it. This is done using the Attachment feature by giving the name of a widget your want to be close to.

Similarly, we want to be able to find a widget and reparent it inside a box where you'd add your other feature. This can be useful when the feature is really tighted to the given widget (i.e. the way the URL is defined in Wordpress it appears in small under the title and that would certainly require a reparenting of the title.)

We defined a "transparent groups" (Group) which allows you to group widgets, but the Group widget itself is 100% virtual (it does not generate any additional HTML code.) This is useful to allow users to add new buttons, edit boxes, check boxes, etc. within that transparent group.

Validation

The validation of data entry includes the following parameters:

Length (minimum, maximum)
Content ([A-Za-z]+)
Data specific validation (a number between 10 and 90 inclusive)
Whether a selection is required (in case of a checkbox, whether it is checked, etc.)
Whether a set of selections is contradictory (i.e. in a list, selecting "None" and other entries.)
Inter-fields validation (i.e. if A is 5, B must be filled with X, Y or Z...)

Permissions

A per widget permission is available. This is important since some of the features defined on a page may require higher permissions for a user to edit that feature. For example you may want to authorized user A to upload attachments, but not user B. This means the attachment widget needs to appear only if the user editing the content has that very permission.

Default Value

Input widgets accept a default value which is different from the current value. (At least Drupal makes it look that way, I'm not so sure we need that distinction here.)

Status

A good idea is for the interface to forbid users from clicking on the buttons until the form is complete. For example, on a registration form, there is really no need for the user to send his data if he has to enter an email address and that email address was not yet entered by the user.

There are several ways to handle these situations:

Block the buttons (i.e. disable or hide them)
Capture the button action and check the form contents on a click; if not yet valid, err and ask the user to fix the problem
Use the Wizard and on the last page show whether there are errors with links to go make corrections (although the Next should not be clickable if there is an error in any intermediate form...)

When completely hidding the buttons, you MUST have inline help to explain what the user has to do next. Otherwise it won't work too well (i.e. the user won't be able to ever get the button to appear and thus submit the result...)

The capture of the button action is a neat trick. This allows for very precise Look Here messages, but it can be tedious to setup (although our system is here to make it dead easy!)

"AJAX Translation"

The ability to translate the interface without directly hitting the server with a GET. This should make the transfer much smaller since only the translated text has to be transfered (and new image URLs when such are also translated, but that is part of the text content anyway.)

This can be done section by section so the site continues to function and the user can click a button and leave the page before we're done stopping the extraneous transfers. Also, some section (banner ads...) could be marked as "no need for on the fly translations."

Print version

For any one page to be printable we should have a way for all the widgets to be displayed for easy print (this would even include a change in the Screen widget so it fits the printer width!)

Snap! A C++ Open Source CMS

Core Features