Make the default UI minimalistic about hallo HOT 22 CLOSED

Agreed. Needs to be some way to insert things though such as images. I think having a toolbar fixed to the top or to the left which has buttons for inserting various things would be good, as drag and drop and hotkeys are not the best for every device.

For instance, on the iPhone there could be a toolbar along the top which has the insert buttons.

Though, this discussion should probably be done as a wiki page instead, as then we can keep expanding on each others ideas, rather than throw them back and forth.

https://github.com/balupton/html5edit/wiki/Roadmap can serve as a type of inspiration

Thoughts?

from hallo.

iOS doesn't allow image insertion from local files anyway, though you could still insert media from remote sources (flickr, whatever). For local files I'd propose supporting only drag-and-drop, but indeed remote media needs some UI element to trigger.

from hallo.

iOS doesn't allow image insertion from local files anyway, though you could still insert media from remote sources (flickr, whatever).

http://picupapp.com/

but indeed remote media needs some UI element to trigger.

sure do :)

from hallo.

Some more information on popover usage in iPad: http://cvil.ly/2010/04/09/ipads-mighty-popover/

jQuery popover plugin: http://jguimont.com/post/786587291/ipad-style-popover-in-jquery

from hallo.

Also, from iPad HIG:

Help people focus on the content by designing your application UI as a subtle frame for the information they’re interested in. Downplay application controls by minimizing their number and prominence.

Makes sense with contentEditables.

from hallo.

There are now basics of the new UX in place:

• When you're writing, there is no UI visible. Only your content, editable and formatted according to your CSS
• When you select something (either via mouse or keyboard), a small floating toolbar appears under the selection, allowing you to do formatting

Still TODOs:

• A bit nicer positioning, ensure the toolbar doesn't overlap with selected text at all
• Consider making it a iPad-style popover to provide context

from hallo.

http://swipe.semsol.com/

from hallo.

@balupton indeed, very close to what I intend!

from hallo.

I think the toolbar should be above+right the select, not bottom-right. Currently it sort of overlaps with the "context" which makes it very hard to start editing when you cant see the text right to the selected text anymore.

from hallo.

Yes, it should not overlap with the selection. Some TODOs for this:

• Make the buttons smaller
• Show only the buttons that can apply to current selection
• Display the buttons in a iPad-like popover

from hallo.

Here is the UI concept:

from hallo.

i think this is an interesting approach. but it probably is really a matter of experience and taste if this is more user friendly than a fixed edit bar that always looks the same or not.

at liip. our ux experts strongly opted for the non-floating approach of a always visible editor at the top of content. you accepted #16 where we add the option to put the editor fixed and always visible. i think this is a good way to allow both approaches (and maybe even let the user choose what he prefers in some configuration settings of your application)
i will try to get some input from our ux guys about their arguments, but they both just went to holiday.

from hallo.

@dbu I'm fully OK with the toolbar staying in place as an option, but I'd prefer the default to be the UX shown above.

from hallo.

great!
eventually when we have nice implementations for both approaches, we should find some ux student who wants to do a field test which approach makes users happier and more productive :-)

from hallo.

http://www.quietwrite.com/ has an interesting concept where all UI elements disappear while you are writing, and reappear if you move your mouse or do something similar. Maybe another idea we could adapt.

from hallo.

i have to admit i am rather old-fashioned. to me an interface that changes and fades in an out is more distracting than one that is just here. i seriously hated the microsoft word (glad that at liip we do everything in a wiki and no more office suites for me) concept of hiding menu entries you did not use recently, as i have to search and see if its there or not and why is it not there...
so my opinion is the less moving and changing and transforming during write the easier i understand what the interface does.

from hallo.

@dbu I think we probably should offer both options:

• The familiar fixed toolbar that other editors have
• Toolbar that only appears when you are making formatting changes

The way to make this manageable would be to detach the toolbar handling from Hallo core, and make both of these options their own Hallo plugins, just like formattings are. Then the separation of concerns would be:

• Hallo core: contentEditable, content changes, content cleanup, allowed formattings for current selection/cursor
• Hallo toolbar: visualizing buttons
• Hallo plugins: registering buttons to the toolbar

from hallo.

yes makes sense. looking forward to the hackfest beginning of january :-)

i suggest keeping it all in the same repo, even if it is logically split. not increase the number of different repos that you need more. even with composer i think it makes it hard to track.

from hallo.

The way to make this manageable would be to detach the toolbar handling from Hallo core, and make both of these options their own Hallo plugins, just like formattings are.

I completely agree. One the biggest challenges to using any other wysiwyg is there is no separation. You can't create your own UI if you want to because it's all integrated. So we create our own. Keeping it separate will allow cleaner code too.

I personally like the toolbar at the top with most options and a contextual menu that fades in near the current selection. If you click on an image it will have just the image options. If you select text it will just have only the bold/italic/link options. Can we allow for this? Maybe a plugin would be given the toolbar as an argument. That would allow a main toolbar to use plugins x, y, and z while a contextual toolbar might just use plugins x and z for a particular selection.

from hallo.

@bergie I am strongly in support of your minimalist aesthetic vision. The quietwrite idea is interesting. I am liking how hallo is working right now also.. I hope to use it in a project pretty soon!

from hallo.

Props for the choice to put the controls back next to the selection rather than having a stupid static toolbar.

from hallo.

@jancborchardt the contextual toolbar described here is the default. But there is also a more traditional fixed toolbar for those who want it. In Hallo toolbars are essentially plugins just like everything else.

from hallo.