Web Browser Missing Widget Work Arounds

Web browsers are either missing or have lackluster or non-standard GUI widgets that client/server and desktop applications readily supplied. It seems we went backward. Such widgets and features include:

Editable Data-Grid - A standard editable "grid" control to provide a spreadsheet-like data grid (see TableBrowser for potential features)
Combo Boxes (hybrid text and drop-down list)
Menus (menus in JavaScript+DOM with frames are a nightmare)
Tabbed sub-portals or sub-forms
Collapsible tree/outline browser, preferably with guide line option. Made popular by Windows Explorer and similar file browsers.
Formatted Masking and/or Validation - Example: Date entry, SSN
Pop-up Dialog Boxes that are smaller than parent to avoid confusion- (Tabbed browsing and IE's security prompts have made the traditional "target=_blank" solution less desirable.)
MDI-style Interfaces - parent window with multiple semi-independent sub-windows, preferably with a minimize (icon-ify), maximize, and "regular size" option.
Right-Click Features or Menus
Modal dialog boxes to reduce confusion and guide the user in a clear fashion. (Modal means they must be satisfied or canceled before closed, hidden, or minimized. A very simple example is the JavaScript "Alert()" box.)
Icon or Object drag-and-drop
WYSIWYG editing - Word-processing-like functionality, or at least MS-Write-like (AKA WordPad).
- See discussion below on CKeditor.

(List originally from WhatIsWrongWithTheGeneralVisualBasicApproach)

Does anybody have suggested work-arounds for these? I know in some cases one can purchase JavaScript widgets that do some of these.

JavaScript grid - http://www.codethat.com/grid - Seems to lack user-sizable columns. One might as well use an HTML table of text-boxes.
JavaScript menus - http://www.cooldev.com/ - Seems to not scale menu item sizes with user-preferred font sizes
Wide collection, OpenSource: http://www.extjs.com/products/extjs/
- Also has support for GoogleWebToolkit: http://www.extjs.com/products/gxt/
See below for other widgets or solution suggestions

There are free jQuery plugins of varying quality for most of these now - http://archive.plugins.jquery.com/

Alternatives to Editable Grid?

An 'editable grid' doesn't need to be a 'widget' in the sense you can get a little blinking cursor in a grid and edit it. Alternatives include the ability to raise a hoverbox into which you can type some contents. This is also well suited to viewing large contents without resizing the entire grid, and providing control over contents.

That's sort of what spreadsheets do, except the "hoverbox" is in the upper left. But when *viewing* data during the edit phase, re-sizable columns are still a nice feature because one can see all the rows with the larger size, not just one cell. And it also allows one to make some less-needed columns narrow to fit more info on one screen. I use this technique often when making screen-shots for colleagues. Plus, their order is usually alterable via dragging. Plus the familiarity factor: people know how to resize and move them already. But I'll welcome a test-drive of an alternative.

I'm not skilled at HtmlDomJsCss myself, but I've seen approaches like this on several of the editable wikis... e.g. where you can click on a link and edit another page right there.

[Putting an editable grid in a web page is a serious sign of BrowserAbuseSyndrome.]

You've lost that war. The world thinks that what Google is doing is a very cool UI, and quite clearly there's no other equally workable approach for Google to do such UIs than with things like Ajax (AjaxWebApplications). Their alternative is to stick to pure HTML, with a correspondingly lame UI, for... what, religious reasons? I don't think so. They obviously don't think so. The world in general likes what Google's been doing. I think the counterarguments have just gone stale, or perhaps refer to a wishful-thinking set of alternatives that doesn't actually exist. And see Ward's 2005 comment on JavaScriptSucksInBrowsers, linked to from BrowserAbuseSyndrome. :-)

I agree with "lost that war". I don't see any good alternatives coming down the road (such as an open-source GUI-browser/protocol), so stretching existing browsers to meet GUI needs seems to be it. Although I am skeptical of AjAx, I welcome their attempt. --top

[I have yet to see a good demo of AjaxWebApplications widgets doing the above.]

You mean an editable grid, only? You don't disapprove of Google's use of Ajax?

[How about a URL of each of the above listed, if possible.]

Question answered, then moved to the page for AjaxWebApplications; take a look.

May I ask for the URL to the editable Ajax data grid? There is no categorization of widgets in those references that I can find.

Do you see above that there was a question, "You mean an editable grid, only? You don't disapprove of Google's use of Ajax?". I don't see an answer to that, so you should not be surprised to find a lack of a link.

That appears to be mostly a graphics-oriented application. "Widgets" are a separate issue.

You've been communicating unclearly, but I now surmise that what you really mean is that an editable grid is just plain missing, not that, if it existed, it would be a sign of BrowserAbuseSyndrome - which is what I thought you meant before.

I agree it may be BrowserAbuseSyndrome, but fancy widgets with web are what businesses really want. If the browser slowly turns into a fat client, at least we find a way to sneak rich-client back into the equation instead of the message==screen current web paradigm.
- Take a step back and reconsider. People used to say "waterfall model is what businesses really want.". Any and all such statements are untrue. Truth is that businesses want maximum profit with minimum expenditure, via business methodology which has clearly definable risk.
  - But nobody agrees on how to achieve "maximum profit", just like any HolyWar that involves many complex interacting and often contradicting factors, including the human psychology of managing software complexity.
- In that sense, "fancy widgets" may be comfortable, and may be the default goal, when no further thought is spent, for some managers and architects in business, but they are not "what businesses really want". Businesses want profit.
- Fancy widgets are, at best, a checklist item ("oooh, shiny") for any business except perhaps those whose central business is selling shiny widgets.
  - Good widgets can greatly simplify the interface or data entry. It is not just about "shiny" factor. For example, if you cannot resize the columns in a data grid, you may have to scroll across each and every cell for every row to make sure there is not "extra" data at the end. -t
- (Even before this most recent exchange, this needs refactoring, because the original discussion was clear as mud.)

Ok, I have no idea whether an editable grid has been done well in AjaxWebApplications. Maybe not. On the other hand, I also don't see what inherently prevents such a thing from being done. Do you?

I know for a fact that there are commercial versions of editable grids written in JavaScript, so it is technically possible (but maybe not easy).

Combo Box

A possible JavaScript/CSS solution: not simple, user-beware - http://particletree.com/features/upgrade-your-select-element-to-a-combo-box/
http://www.vttoth.com/htmcombo.htm

Re: Tabbed sub-portals or sub-forms"

A left-side navigation panel/tree may be a sufficient alternative if browser does not have to redraw each "hidden" data panel (right panel).

CKeditor - WYSIWYG editor

I've fiddled with CKeditor a bit, but it has too many quirks and is a PITA to customize.

[CKEditor is excellent. Any difficulties are due to your own inadequacy.]

I guess I'm just dumb. I can think of 10 different ways its app interface could be smoother, and they ignored all of them. And the author agreed that some oddities I pointed out should be fixed.....someday. Another feature that's almost a show-stopper is that it cannot center images; and people have been asking for it for a good long time. Perhaps the purpose or usage patterns you needed it for are different than mine.

[That's because you can't centre images in HTML using the img tag. In fact, <img ...> alignment is deprecated in HTML 4 and not even supported in HTML5. CKEditor is a WYSIWYG HTML editor, not a desktop publishing layout tool. How could CKEditor's app interface be smoother?]

Have it not use the IMG tag to center align, but put the image inside a centered DIV. True, the implementation is more involved, especially if one changes it back to left or right, but that's not the same as "can't be done". I'll leave the "smoother" discussion for another day.

[I didn't say it can't be done at all; I said it can't be done using the img tag. As you pointed out, it has to be done inside a centred DIV. It's not the intent of CKEditor to create compound constructs.]

The bottom line is that our org wants content authors to be able to have centered images and CKEditor is not delivering.

[Nice thing about OpenSource is you can fix that.]

In theory. In practice I'd have to take the time to figure out the internal framework, hope I don't cause unexpected side-effects with my change, and am stuck in time with my custom fork version.

[All true, but what's the alternative? Wish for the perfect widget until it magically materialises?]

We rigged a work-around. It's a long, winding story.

By the way, does anybody know how the user can rid accidental paragraph tags in table cells? Deleting spaces before and after doesn't work. P tags inside make the row too "thick".

I misread this as WebBrowserMissingWgetWorkArounds, which might be an interesting topic of its own.

CategoryWebDesign, CategoryInternet, CategoryUserInterface, CategoryGui