Comments (22)
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).
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.
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.
Related Issues (20)
- README.md documentation confusing
- Paste image from clipboard
- anyone know the function to get contents HOT 1
- Problem with cite tag and hallo.js HOT 2
- Extra headers with halloheadings plugin
- Bower dependencies
- Hallo is leaving 'ui-droppable' on paragraph elements HOT 1
- XSS possible by firstly disabling Javascript and entering some script HOT 1
- Html mixed with markdown when making an UL
- Pressing the Esc key loses changes
- The event `hallomodified` is not fired when pasting data in mobile Safari
- Project health? HOT 4
- Basic Question: How does the user save changes? HOT 1
- "halloactivated" event handler isn't unhooked on destroy()
- Is there any chance there will be a plugin guide
- Version 10 of node.js has been released
- An in-range update of grunt-bower-install-simple is breaking the build π¨ HOT 4
- An in-range update of grunt is breaking the build π¨ HOT 2
- An in-range update of grunt-saucelabs is breaking the build π¨ HOT 1
- Hello world
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hallo.