"Widget" is a funny word. There might be others. We should talk about how these get displayed to the end user.

Comments

yched’s picture

yched CreditAttribution: yched commented

Hm, this terminology thing about 'widget' has been around since CCK 4.7 ;-).
I have no major problem with replacing by a better term if we find one (although renaming in the code is gonna be... fun), but this new term has to be one-word IMO.

yched’s picture

yched CreditAttribution: yched commented
Component: field system » field_ui.module
petsagouris’s picture

petsagouris CreditAttribution: petsagouris commented

I've always looked on "widgets" as "methods" basically.

This is how my train of thought has developed in the last six months of tinkering with drupal and drupal module development:

Field (of) type (using) widget method (displayed by) formatter

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

Second guy had great feedback on individual items in the forms.

Such as when he explained what he thought weight was. He was correct, but we probably should rename Weight to Order.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

Re Wizards. Especially the first guy had problems understanding what happened when he created fields and stuff that walked him through multiple pages (steps).

Would be good if the title included for example "Step x of y" and the save button was named "Continue" until the last step.

Actually, looking more at these, we have actually taken shortcuts and mixed in these wizard creations with the edit interfaces for example for existing fields.

Best would be to completely redesign them using a modal interface when adding/reusing/editing a field. That way the list of fields would always be in the background and users will know that when the modal is open they are working with that specific field until the modal closes.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

In general though we should have a big pow-wow not only for the improvements that are needed for the core UI, but also for some of the big modules out there such as Views, Rules, Page Manager, Panels, Flag, Display Suit, Workbench, Media and so on.

Core wont need all the UI features and terminology that they need/add, but we need to coordinate so that things get as unified as possible.

This is getting even more important now with HTML5 that are providing possibilities for UI design that previously was much more difficult without lots of advanced JavaScripts.

Since there seems to be a goal that Core shall be a framework, then Core will need to contain UI features that is not used bu core, but needed by contribs.