Publish_v1 Mockup
Khaled Abou Alfa
http://www.brokenkode.com/habaridev/publish_v1.png
This is my first stab at it. I've expanded on the sketch that Owen did.
This is just to get the structure and get us thinking about how we
actually want everything working. Draw a line in the sand and move on
from there really. I've specifically not given any colours here, and
kept it basically greys. I'm not sure what colours we should go for in
the end but I've taken the point that it should be warm colours rather
than blues (and anyway I've already done blue).
Regarding the media browser, I've not really expanded on this much to be
honest with you, and so I'll try and do that in the next version. I've
got another idea for this, however I don't know whether we can implement
it (although I'm pretty sure we can) which would definitely make things
easier to use in general.
So as I described before we've got three elements of concern. The
Publish, the Manage and the Admin.
The main post area is limited to the bare essentials (at first), and
this is in advanced mode btw, I'll expand further on the advanced and
the beginner's options in later versions.
The side panel can be hidden as a number of things are only added when
you want them specifically. For example a friend of mine doesn't use
categories (he's only got one) and he doesn't care for anything else
apart from title, post and uploading images. Everything else is
completely irrelevant to him. Of course that's one extreme but my point
is that different people use it in different ways and as such we should
ideally look to cater for people that like to hide the clutter as well.
The way in which this is implemented I guess is completely up to you
guys. I'd love for some funky animations to roll the side panel up, but
like I said I'll keep those kind of specifics up to you.
The side panel can be expanded on as more elements can be added from the
admin pages, I've only shown the categories and something called
snippets which I'll expand on.
Basically Snippets can be thought of like the shelf in Flock. I like it
as an idea, but I'm not really interested in using it as my main
browser. So (and I don't know if this is possible) I'd like to be able
to collect various things around before I blog them. Any chance of
getting something like this implemented?
One thing that I remember people mentioned after we finished the designs
on Shuttle was how it was disappointing that we didn't think to add the
option to have a dropdown menu from the main menu with any other
elements under that particular page. What are people's thoughts on this?
Should we have that option available. We'd probably make use of it in
the manage and administration areas, but I'm wouldn't really be of much
use for the publish page (unless I'm forgetting something).
Anyways let the discussions begin.
Rich Bowen
On Nov 22, 2006, at 19:14, Khaled Abou Alfa wrote:
>
> Basically Snippets can be thought of like the shelf in Flock. I
> like it
> as an idea, but I'm not really interested in using it as my main
> browser. So (and I don't know if this is possible) I'd like to be able
> to collect various things around before I blog them. Any chance of
> getting something like this implemented?
You've described it by saying it's like something else I've never
heard of. Can you possibly elaborate further? What is this thing,
what's it used for, and why would we want to implement it?
Thanks.
khaled....@gmail.com
It's got something called the shelf which basically you collect
information, snippets, links, quotes, images whatever and then you use
them when you're about to blog. Could we have a feature like this using
an applet that can sit as a link and comes up? Not sure about the
specifics, it's just another idea to throw in here and see what sticks.
Sorry should have been more clear.
Rich Bowen
Sorry to appear dense. I'm vaguely aware of Flock (although I've
never used it). Mostly, however, I want to avoid having feature
requests phrased in terms that don't convey any actual information to
someone who wants to implement it.
The concept sounds interesting. I think it's probably something that
we want to push back a version or two. Or perhaps it's a good idea
for a plugin.
Scott Merrill
> http://www.brokenkode.com/habaridev/publish_v1.png
Good start! It gives us something concrete to look at as we discuss things.
> Regarding the media browser, I've not really expanded on this much to be
> honest with you, and so I'll try and do that in the next version. I've
> got another idea for this, however I don't know whether we can implement
> it (although I'm pretty sure we can) which would definitely make things
> easier to use in general.
The "media browser" in the mockup isn't much of a browser, but more an
upload widget.
How's this: a media browser might exist in the side panel somewhere,
and provide a (vertical) scrollable list of image thumbnails. Video and
audio media might need either a different tab in the browser, or some
sort of integrated player so that one can preview the media.
One could drag the media from the sidebar; or perhaps simply
(double-)clicking on the media would insert the appropriate HTML in the
post composition box.
At the top or bottom (or both) of the media list is a link to upload new
media. This link should pop up a window (AJAX, maybe?) from which one
uploads the media. After upload, the thumbnail should be visible in the
media list.
> The main post area is limited to the bare essentials (at first), and
> this is in advanced mode btw, I'll expand further on the advanced and
> the beginner's options in later versions.
What constitutes "advanced" post composition / editing?
I'd say that the supplied screen looks more like "basic" mode rather
than advanced. "Basic" mode would be just those items that are
absolutely required. "Advanced" mode would be those extra bits that
aren't necessary and which override default behaviours.
Things that probably need to be on the basic screen:
* tag entry
* post status (publish, draft)
* date/time override
Ideally, I'd like to be able to switch from basic to advanced mode
without losing any edits I might be making. The "advanced" screen may
just be a panel that expands when clicked (though see below).
Things that belong on the advanced screen:
* visibility modifiers (possibly implemented via magic tags)
* post-slug modification
* opened / closed commenting
* media stuff?
* pingbacks / trackbacks?
> The side panel can be hidden as a number of things are only added when
> you want them specifically. For example a friend of mine doesn't use
> categories (he's only got one) and he doesn't care for anything else
> apart from title, post and uploading images. Everything else is
> completely irrelevant to him. Of course that's one extreme but my point
> is that different people use it in different ways and as such we should
> ideally look to cater for people that like to hide the clutter as well.
> The way in which this is implemented I guess is completely up to you
> guys. I'd love for some funky animations to roll the side panel up, but
> like I said I'll keep those kind of specifics up to you.
Speaking solely for myself, I would _not_ like funky animations.
Also speaking solely for myself, I am of the opinion that we should keep
to an absolute minimum the number of UI elements that one can hide. If
it can be hidden, it makes me wonder how much it really needs to be
included at all. (This contradicts my comments about the advanced
editing controls above, of course)
Khaled, in an earlier email you proposed the idea of a customizable post
composition screen, such that one could select those elements you want
to see, and completely suppress others. I like this idea as a per-user
option, and would prefer to pursue it than panels that one can hide.
> Basically Snippets can be thought of like the shelf in Flock. I like it
> as an idea, but I'm not really interested in using it as my main
> browser. So (and I don't know if this is possible) I'd like to be able
> to collect various things around before I blog them. Any chance of
> getting something like this implemented?
If I understand your description of this "shelf", we'd need some kind of
scriptlet that one could use to populate the shelf. I think that's
probably a bit beyond our current intentions. If I mis-understand, do
please illuminate.
> One thing that I remember people mentioned after we finished the designs
> on Shuttle was how it was disappointing that we didn't think to add the
> option to have a dropdown menu from the main menu with any other
> elements under that particular page. What are people's thoughts on this?
> Should we have that option available. We'd probably make use of it in
> the manage and administration areas, but I'm wouldn't really be of much
> use for the publish page (unless I'm forgetting something).
I think it ought to be easy for plugins to add new UI elements to the
post composition screen. Each of these new elements should be clearly
marked in some way. I'm wary of allowing plugins to override or
suppress default Habari elements.
I'm currently ambivalent on the idea of drop-down menus.
--
ski...@skippy.net | http://skippy.net/
gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49 3544 476A 7DEC 9CFA 4B35
Owen Winkler
>
> Khaled Abou Alfa wrote:
> > http://www.brokenkode.com/habaridev/publish_v1.png
>
> Good start! It gives us something concrete to look at as we discuss things.
Yep. I especially like that you've taken my design a step further.
I'll just assume that you thought it was a good idea, too. :)
> > Regarding the media browser, I've not really expanded on this much to be
> > honest with you, and so I'll try and do that in the next version. I've
> > got another idea for this, however I don't know whether we can implement
> > it (although I'm pretty sure we can) which would definitely make things
> > easier to use in general.
>
> The "media browser" in the mockup isn't much of a browser, but more an
> upload widget.
Agreed. I would like to see something more like a file manager, ala
my Exhibit plugin for WordPress.
There are many problems with attaching images to posts, and I learned
a lot about the practicalities of this while developing Exhibit.
People want to organize their images into some logical structure.
They want to be able to easy search for and include those images.
They want a web-based upload that handles more than one file, isn't
clunky, and puts their files onto the server in a place that makes
sense to them (as opposed to an arbitrary date-based system, like some
other tools). And, perhaps most importantly, they want to be able to
use *real* tools, like FTP, to put their files online and then still
be able to select those files to include in posts.
So, along those lines, yes, I would like to see something more robust.
> How's this: a media browser might exist in the side panel somewhere,
> and provide a (vertical) scrollable list of image thumbnails. Video and
> audio media might need either a different tab in the browser, or some
> sort of integrated player so that one can preview the media.
This whole idea sounds good, and it was my first thought, too. Does
this mean that the sidebar is not present on every page of the admin?
Or that there are component parts of the sidebar that are not on every
page of the admin? That makes things more complicated.
I'm not saying I think that one way's better, just wondering what y'all think.
> > The main post area is limited to the bare essentials (at first), and
> > this is in advanced mode btw, I'll expand further on the advanced and
> > the beginner's options in later versions.
> Ideally, I'd like to be able to switch from basic to advanced mode
> without losing any edits I might be making. The "advanced" screen may
> just be a panel that expands when clicked (though see below).
> Speaking solely for myself, I would _not_ like funky animations.
>
> Also speaking solely for myself, I am of the opinion that we should keep
> to an absolute minimum the number of UI elements that one can hide. If
> it can be hidden, it makes me wonder how much it really needs to be
> included at all. (This contradicts my comments about the advanced
> editing controls above, of course)
I agree. If anything hides at all, it should be just one hiding area.
All of the controls that can be hidden reside in this area, and when
you activate the hiding, they all hide. Also, if it's possible to
stem the tide of debate over whether user-settings can affect the
default visibility of that hidden area, I'd like to do that, too.
> Khaled, in an earlier email you proposed the idea of a customizable post
> composition screen, such that one could select those elements you want
> to see, and completely suppress others. I like this idea as a per-user
> option, and would prefer to pursue it than panels that one can hide.
Yes, me too.
> > Basically Snippets can be thought of like the shelf in Flock. I like it
> > as an idea, but I'm not really interested in using it as my main
> > browser. So (and I don't know if this is possible) I'd like to be able
> > to collect various things around before I blog them. Any chance of
> > getting something like this implemented?
>
> If I understand your description of this "shelf", we'd need some kind of
> scriptlet that one could use to populate the shelf. I think that's
> probably a bit beyond our current intentions. If I mis-understand, do
> please illuminate.
Not being Flock users, I think we're all pretty unfamiliar with how
this would work. I don't know enough about the concept to have a real
opinion, but it sounds like a neat idea. And in agreement with Rich's
thoughts on the topic- You need to describe the feature well enough so
that people who don't have experience with it can implement it.
> > One thing that I remember people mentioned after we finished the designs
> > on Shuttle was how it was disappointing that we didn't think to add the
> > option to have a dropdown menu from the main menu with any other
> > elements under that particular page. What are people's thoughts on this?
> > Should we have that option available. We'd probably make use of it in
> > the manage and administration areas, but I'm wouldn't really be of much
> > use for the publish page (unless I'm forgetting something).
I'm not sure what you mean by this. What menus are you talking about?
I'll comment that in particular, I *hate* the dropdown menus that are
in every other CMS product out there. You can't see the sub-options
that the menu has without putting your mouse over or clicking an
option, and they're *required* for use. It might have been better if
the suboptions for just the current menu were present with the option
to drop down the others (and save a click), but requiring the
dropdowns in toto to operate the product seems like very poor UI
design to me.
In general, I'm very positive about this first design. It's spiffy.
Owen
Broken Kode
> Khaled Abou Alfa wrote:
> > http://www.brokenkode.com/habaridev/publish_v1.png
>
> Good start! It gives us something concrete to look at as we discuss things.
>
> > Regarding the media browser, I've not really expanded on this much to be
> > honest with you, and so I'll try and do that in the next version. I've
> > got another idea for this, however I don't know whether we can implement
> > it (although I'm pretty sure we can) which would definitely make things
> > easier to use in general.
>
> The "media browser" in the mockup isn't much of a browser, but more an
> upload widget.
Well that's just the first part of the browser, but I'll explain a
little later.
> How's this: a media browser might exist in the side panel somewhere,
> and provide a (vertical) scrollable list of image thumbnails. Video and
> audio media might need either a different tab in the browser, or some
> sort of integrated player so that one can preview the media.
>
> One could drag the media from the sidebar; or perhaps simply
> (double-)clicking on the media would insert the appropriate HTML in the
> post composition box.
>
> At the top or bottom (or both) of the media list is a link to upload new
> media. This link should pop up a window (AJAX, maybe?) from which one
> uploads the media. After upload, the thumbnail should be visible in the
> media list.
There's a couple of things we need to be wary of and that's making it
usable to those users without a mouse. Ease of use and understanding is
key here and it should be instantly understandable how to move media
from the 'browser' to the post field itself. So the controls of how you
move the media is paramount and might have to be spelled out.
Also I think that the media browser should take an equal billing on the
page as the post title and post content fields. The way in which Habari
will be handling media is effectively one (of many) things that will
distinguish it over the competition. So I don't think we should religate
it to the sidebar because of that reason.
The mockup shows the uploading element like you say. Maybe then when you
log in the content in the media browser is shown (so you might want to
use older images or whatever and then there is a link which brings up
the uploader element (I'm thinking making it all look like the way
feedlounge handles pop-ups)?
On the side of the media browser you could have individual media
controls. What I mean by that is either a series of radio buttons when
you highlight and then click which will allow you to edit (could be
associated tags, name, description or whatever) and another for insert
into post?
I'm thinking out loud right now so please excuse the jumbled mess :).
>
> > The main post area is limited to the bare essentials (at first), and
> > this is in advanced mode btw, I'll expand further on the advanced and
> > the beginner's options in later versions.
>
> What constitutes "advanced" post composition / editing?
Well in my mind basic includes text descriptions of what everthing
actually is. I'm thinking of this from a usablity pov. The explanations
need not be in there all the time for some one who's used the programme
for more than 2 days, but in the first instance to get him/her up to
speed we need to explain things. Once they're happy they understand what
everything does they can turn it off.
>
> I'd say that the supplied screen looks more like "basic" mode rather
> than advanced. "Basic" mode would be just those items that are
> absolutely required. "Advanced" mode would be those extra bits that
> aren't necessary and which override default behaviours.
>
> Things that probably need to be on the basic screen:
> * tag entry
> * post status (publish, draft)
> * date/time override
>
> Ideally, I'd like to be able to switch from basic to advanced mode
> without losing any edits I might be making. The "advanced" screen may
> just be a panel that expands when clicked (though see below).
>
> Things that belong on the advanced screen:
> * visibility modifiers (possibly implemented via magic tags)
> * post-slug modification
> * opened / closed commenting
> * media stuff?
> * pingbacks / trackbacks?
See that's where I disagree. Those things might be important to you,
maybe to me, but the other guy over there might not really care for
post-slug or pingbacks. We should I guess agree on the bare minimum that
the default advanced is setup with, however it's equally as important to
make sure that the flexibility to "hide" those additional elements away
as an option. Give the user the power to decide what he wants and
doesn't want to see. Our blogs look different, why shouldn't the
software that runs the site have the ability to cater to my needs?
>
> > The side panel can be hidden as a number of things are only added when
> > you want them specifically. For example a friend of mine doesn't use
> > categories (he's only got one) and he doesn't care for anything else
> > apart from title, post and uploading images. Everything else is
> > completely irrelevant to him. Of course that's one extreme but my point
> > is that different people use it in different ways and as such we should
> > ideally look to cater for people that like to hide the clutter as well.
> > The way in which this is implemented I guess is completely up to you
> > guys. I'd love for some funky animations to roll the side panel up, but
> > like I said I'll keep those kind of specifics up to you.
>
> Speaking solely for myself, I would _not_ like funky animations.
And as another option animations could(?) be taken off. It's all about
allowing you to have the panel as you see fit. You're right many would
get annoyed with that, however other wouldn't and find the software more
fun to use as a consequence. It's not all about you dear sir :) lol.
>
> Also speaking solely for myself, I am of the opinion that we should keep
> to an absolute minimum the number of UI elements that one can hide. If
> it can be hidden, it makes me wonder how much it really needs to be
> included at all. (This contradicts my comments about the advanced
> editing controls above, of course)
>
> Khaled, in an earlier email you proposed the idea of a customizable post
> composition screen, such that one could select those elements you want
> to see, and completely suppress others. I like this idea as a per-user
> option, and would prefer to pursue it than panels that one can hide.
Completely in agreement there. That's why only the sidepanel can be
hidden. It might be a case that in the main body we have some things
that can be added in those areas (like custom fields) because they're
too large to fit into the sidepanel, but yeah you're right.
>
> > Basically Snippets can be thought of like the shelf in Flock. I like it
> > as an idea, but I'm not really interested in using it as my main
> > browser. So (and I don't know if this is possible) I'd like to be able
> > to collect various things around before I blog them. Any chance of
> > getting something like this implemented?
>
> If I understand your description of this "shelf", we'd need some kind of
> scriptlet that one could use to populate the shelf. I think that's
> probably a bit beyond our current intentions. If I mis-understand, do
> please illuminate.
Well to be honest the shelf idea I threw in there because it's one of
those ideas that I liked from FLock, tried using the browser but not
really interested, but I think that feature would be something I might
actually enjoy using. If I come up with an idea that might allow us to
implement it I'll get back in there :).
Scott Merrill
>> One could drag the media from the sidebar; or perhaps simply
>> (double-)clicking on the media would insert the appropriate HTML in the
>> post composition box.
>>
>> At the top or bottom (or both) of the media list is a link to upload new
>> media. This link should pop up a window (AJAX, maybe?) from which one
>> uploads the media. After upload, the thumbnail should be visible in the
>> media list.
>
> There's a couple of things we need to be wary of and that's making it
> usable to those users without a mouse. Ease of use and understanding is
> key here and it should be instantly understandable how to move media
> from the 'browser' to the post field itself. So the controls of how you
> move the media is paramount and might have to be spelled out.
You raise a good point re: mouse navigation. I hadn't considered
keyboard-only navigation.
Your comment "it should be instantly understandable" contradicts a wee
bit your comment below about the "basic" editing screen. See below for
my thoughts.
> Also I think that the media browser should take an equal billing on the
> page as the post title and post content fields. The way in which Habari
> will be handling media is effectively one (of many) things that will
> distinguish it over the competition. So I don't think we should religate
> it to the sidebar because of that reason.
But, in staying consistent with your comments below, it sounds like the
media component should also be something that can be 'switched off' per
user preference, right?
At any rate, I don't consider putting something in the sidebar as akin
to making it less important. I suggested putting it in the sidebar
simply for space-saving reasons, so that it might be possible to have it
live above the fold of the screen, but still give prominence to the
text-entry field.
> The mockup shows the uploading element like you say. Maybe then when you
> log in the content in the media browser is shown (so you might want to
> use older images or whatever and then there is a link which brings up
> the uploader element (I'm thinking making it all look like the way
> feedlounge handles pop-ups)?
I've never used FeedLounge. As Rich asked earlier, please try to
describe features in functional terms without relying on vague
comparisons to niche tools. How does FeedLounge handle pop-ups?
> On the side of the media browser you could have individual media
> controls. What I mean by that is either a series of radio buttons when
> you highlight and then click which will allow you to edit (could be
> associated tags, name, description or whatever) and another for insert
> into post?
Good point: I hadn't considered editing media metadata from within a
post composition window.
I assume we'd want some means to manage media independent of creating a
new post. If we create one "media management widget", we could give
that widget a dedicated page for independent media management, and we
could embed that same widget into a small div (or iframe?) somewhere on
the post composition screen.
>> What constitutes "advanced" post composition / editing?
> Well in my mind basic includes text descriptions of what everthing
> actually is. I'm thinking of this from a usablity pov. The explanations
> need not be in there all the time for some one who's used the programme
> for more than 2 days, but in the first instance to get him/her up to
> speed we need to explain things. Once they're happy they understand what
> everything does they can turn it off.
I strongly disagree with the idea that descriptive help text be placed
on the post composition screen. Just as you want media management to be
as intuitive as possible, so I want the post composition screen. We
should strive to label each field with a meaningful name that people can
readily understand.
I would prefer that each field have a help link (a question mark icon,
the literal word "help", or some other indicator) that opens up the
appropriate portion of the Habari manual. In this way, the screen stays
focused on the act of writing a post, but complete help text is provided.
I think that the Habari manual should be bundled in HTML with the
product, so that one can read it at one's leisure. Then we can link all
the screens to the appropriate manual locations. This minimizes
duplication of manual content. It also ensures that help text is
available on each Habari installation, and that our users are not
beholden to some documentation server we host.
>> Things that belong on the advanced screen:
>> * visibility modifiers (possibly implemented via magic tags)
>> * post-slug modification
>> * opened / closed commenting
>> * media stuff?
>> * pingbacks / trackbacks?
>
> See that's where I disagree. Those things might be important to you,
> maybe to me, but the other guy over there might not really care for
> post-slug or pingbacks.
I understand. These "advanced" controls would be hidden by default,
because they are not things that most people regularly use (or so I assume).
Perhaps the terms "basic" and "advanced" are inappropriate. Perhaps, in
keeping with the idea of per-user screen layout, what I've been calling
the "basic" tools would simply be those tools that the user has selected
as visible. What I've been calling "advanced" would be all those tools
that the user has elected not to see.
I worry about making some tool completely inaccessible, though. How
would one handle the situation where they've elected to suppress the
trackback field because they don't ever send trackbacks and suddenly
they realize they have a need to send one? If their set of "suppressed"
controls resides in a panel which can be expanded, they get their
preferred composition layout but still have access to all the Habari
tools...
> however it's equally as important to
> make sure that the flexibility to "hide" those additional elements away
> as an option. Give the user the power to decide what he wants and
> doesn't want to see. Our blogs look different, why shouldn't the
> software that runs the site have the ability to cater to my needs?
As I said in my previous email, I think we should be wary of making too
many things disable-able on the post composition screen. Habari should
have a specific minimum set of items per post which cannot be disabled.
We should work toward consensus on what that bare minimum set of items
might be, and discuss along the way how best to support the addition /
suppression of other items.
>> Speaking solely for myself, I would _not_ like funky animations.
>
> And as another option animations could(?) be taken off. It's all about
> allowing you to have the panel as you see fit. You're right many would
> get annoyed with that, however other wouldn't and find the software more
> fun to use as a consequence. It's not all about you dear sir :) lol.
I understand it's not all about me, but we'll have a very hard time
moving forward if we don't try to reach some consensus about bare
minimum defaults. There's also a cost/benefit issue that we should
evaluate: is the cost of making fancy animations and an associated UI
control to enable/disable them worth the effort? How will we judge
whether users like the fancy animations, or if everyone simply disables
them on the third time they see them?
>> If I understand your description of this "shelf", we'd need some kind of
>> scriptlet that one could use to populate the shelf. I think that's
>> probably a bit beyond our current intentions. If I mis-understand, do
>> please illuminate.
>
> Well to be honest the shelf idea I threw in there because it's one of
> those ideas that I liked from FLock, tried using the browser but not
> really interested, but I think that feature would be something I might
> actually enjoy using. If I come up with an idea that might allow us to
> implement it I'll get back in there :).
Do please explain the idea more. I haven't used Flock, so I'm still
fuzzy on what benefit the "shelf" has to a blog. I'm not criticizing
it: I am ignorant of it, and would like to know more.
Broken Kode
No no no, the media browsers is one of the main components of the actual
page and therefore should be there by default. One of those things that
has to be there, much in the same way the title and the post content
fields have to be there as a minimum. Those three elements are the bare
essential things that as a blogger you would need. I see everything else
as additional elements that give you more control but their necessities
is seriously dependant on the eventual user. I don't bother with
password protected pages, other people might. I don't bother with
changing the date of when something was posted, others might. And so on
and so forth.
We should include the ability to put all these additional controls in
there but the user shouldn't be subjected to things he's honestly not
interested in. CLutter makes for bad karma. But you make a good point
about what happens when they want something and it's not available? This
might be solvable when we get to the administration panel page which
should address this.
>
> At any rate, I don't consider putting something in the sidebar as akin
> to making it less important. I suggested putting it in the sidebar
> simply for space-saving reasons, so that it might be possible to have it
> live above the fold of the screen, but still give prominence to the
> text-entry field.
>
> > The mockup shows the uploading element like you say. Maybe then when you
> > log in the content in the media browser is shown (so you might want to
> > use older images or whatever and then there is a link which brings up
> > the uploader element (I'm thinking making it all look like the way
> > feedlounge handles pop-ups)?
>
> I've never used FeedLounge. As Rich asked earlier, please try to
> describe features in functional terms without relying on vague
> comparisons to niche tools. How does FeedLounge handle pop-ups?
Popups come up in a lightbox rather than a popup per say. It's the new
pop up. Blacks out the background and provides you with the form without
having left the page. (www.brokenkode.com/illustration for an example ).
>
> > On the side of the media browser you could have individual media
> > controls. What I mean by that is either a series of radio buttons when
> > you highlight and then click which will allow you to edit (could be
> > associated tags, name, description or whatever) and another for insert
> > into post?
>
> Good point: I hadn't considered editing media metadata from within a
> post composition window.
>
> I assume we'd want some means to manage media independent of creating a
> new post. If we create one "media management widget", we could give
> that widget a dedicated page for independent media management, and we
> could embed that same widget into a small div (or iframe?) somewhere on
> the post composition screen.
Good idea (maybe not the iframe). I'll try and move this element forward
a bit this weekend so that we can thrash it out a bit more.
>
> >> What constitutes "advanced" post composition / editing?
> > Well in my mind basic includes text descriptions of what everthing
> > actually is. I'm thinking of this from a usablity pov. The explanations
> > need not be in there all the time for some one who's used the programme
> > for more than 2 days, but in the first instance to get him/her up to
> > speed we need to explain things. Once they're happy they understand what
> > everything does they can turn it off.
>
> I strongly disagree with the idea that descriptive help text be placed
> on the post composition screen. Just as you want media management to be
> as intuitive as possible, so I want the post composition screen. We
> should strive to label each field with a meaningful name that people can
> readily understand.
>
> I would prefer that each field have a help link (a question mark icon,
> the literal word "help", or some other indicator) that opens up the
> appropriate portion of the Habari manual. In this way, the screen stays
> focused on the act of writing a post, but complete help text is provided.
>
> I think that the Habari manual should be bundled in HTML with the
> product, so that one can read it at one's leisure. Then we can link all
> the screens to the appropriate manual locations. This minimizes
> duplication of manual content. It also ensures that help text is
> available on each Habari installation, and that our users are not
> beholden to some documentation server we host.
Well it could be done in that way, I'm not overtly precious about the
subject to be honest, as long as the really novice user gets more
information when he needs it regarding all the specific elements on the
page, either with a help link or with descriptive text then I'm cool,
because I think it's an important issue to making people understand what
it is they're looking at.
>
> >> Things that belong on the advanced screen:
> >> * visibility modifiers (possibly implemented via magic tags)
> >> * post-slug modification
> >> * opened / closed commenting
> >> * media stuff?
> >> * pingbacks / trackbacks?
> >
> > See that's where I disagree. Those things might be important to you,
> > maybe to me, but the other guy over there might not really care for
> > post-slug or pingbacks.
>
> I understand. These "advanced" controls would be hidden by default,
> because they are not things that most people regularly use (or so I assume).
>
> Perhaps the terms "basic" and "advanced" are inappropriate. Perhaps, in
> keeping with the idea of per-user screen layout, what I've been calling
> the "basic" tools would simply be those tools that the user has selected
> as visible. What I've been calling "advanced" would be all those tools
> that the user has elected not to see.
>
> I worry about making some tool completely inaccessible, though. How
> would one handle the situation where they've elected to suppress the
> trackback field because they don't ever send trackbacks and suddenly
> they realize they have a need to send one? If their set of "suppressed"
> controls resides in a panel which can be expanded, they get their
> preferred composition layout but still have access to all the Habari
> tools...
Point taken, which is where I think the admin panel front page comes
into play. This would have some descriptions of the various things that
you can do and handle which is why it's a pretty important page overall
for the control of your site etc. I see these pages having more
descriptions to be honest, so that the end user really doesn't need to
faf around and get to the point with ease.
>
> > however it's equally as important to
> > make sure that the flexibility to "hide" those additional elements away
> > as an option. Give the user the power to decide what he wants and
> > doesn't want to see. Our blogs look different, why shouldn't the
> > software that runs the site have the ability to cater to my needs?
>
> As I said in my previous email, I think we should be wary of making too
> many things disable-able on the post composition screen. Habari should
> have a specific minimum set of items per post which cannot be disabled.
> We should work toward consensus on what that bare minimum set of items
> might be, and discuss along the way how best to support the addition /
> suppression of other items.
Completely agree. My vote is as such:
Main:
Post Title
Post Content
Media Browser
Sidebar:
Categories
Allow Comments/ Allow trackbacks/ Allow Pings
Everything else can be added when you need it. I know it'll look bare,
but it removes the clutter.
We just have to make it very clear in the admin panel that this is as
simple as pie and how to do it and I don't think we'll have a problem.
> >> Speaking solely for myself, I would _not_ like funky animations.
> >
> > And as another option animations could(?) be taken off. It's all about
> > allowing you to have the panel as you see fit. You're right many would
> > get annoyed with that, however other wouldn't and find the software more
> > fun to use as a consequence. It's not all about you dear sir :) lol.
>
> I understand it's not all about me, but we'll have a very hard time
> moving forward if we don't try to reach some consensus about bare
> minimum defaults. There's also a cost/benefit issue that we should
> evaluate: is the cost of making fancy animations and an associated UI
> control to enable/disable them worth the effort? How will we judge
> whether users like the fancy animations, or if everyone simply disables
> them on the third time they see them?
It's all about happy compromises isn't it. There's always a balance to
be achieved as you say. Which is more important, functionality or silly
animations? I'll be the first to tell you funky animations :), no only
joking. Functionality is very important, however I think we shouldn't
loose track of the fact that blogging should be more fun. You should be
excited about opening up your browser and throwing yourself into all of
this.
Simplicity will aid in this, ease of use will aid in this, however a
small portion of that fun might also come from the simple fact that
we've taken into account the little things in life. Taken care of the
details. And while those details might not be important at this
particular moment in time I agree, I still think they should be put on
the map for when the community gets someone who thinks that this is
really an area habari is lacking and he's got both the time/effort/skill
and knowledge to tackle it.
We should just keep these things in mind to make sure that when we want
to include them we can....is all I'm saying :).
>
> >> If I understand your description of this "shelf", we'd need some kind of
> >> scriptlet that one could use to populate the shelf. I think that's
> >> probably a bit beyond our current intentions. If I mis-understand, do
> >> please illuminate.
> >
> > Well to be honest the shelf idea I threw in there because it's one of
> > those ideas that I liked from FLock, tried using the browser but not
> > really interested, but I think that feature would be something I might
> > actually enjoy using. If I come up with an idea that might allow us to
> > implement it I'll get back in there :).
>
> Do please explain the idea more. I haven't used Flock, so I'm still
> fuzzy on what benefit the "shelf" has to a blog. I'm not criticizing
> it: I am ignorant of it, and would like to know more.
Ok I'll explain the shelf idea. I don't know how this could be
integrated into habari. I've thrown it in here for discussion to see if
there might be a way I have no idea about. The shelf is basically a
panel that sits at the bottom of the page. You activate it by clicking
the shelf icon. From there you can literally drag and drop highlighted
text into it and it will see it as a seperate component. Or a weblink
can be dragged and dropped. This way, while you're blogging you're
collecting data and information about your post.
Now the shelf is browser specific, however I would like to be able to
have the same function of collecting data but having all that
information sit in my web application of choice and publishing from
there. How this could be made to work, I'll be honest I have no idea.
Chris J. Davis
here, other than to bring up one thing, point out another and give an
alternate explanation of the "shelf".
1.) We aren't going to have categories per se (this is for Khaled),
we have decided to go with tagging as the method of organization in
Habari, with the ability to make 'super tags' that would group tags
into 'sets'. (see http://www.chrisjdavis.org/explore/my/mind for an
example. Mind would be a super tag that contains all the other tags
you see on that page.) I am sure this is open to debate.
2.) We (being the code monkeys) have spoken at length about how Posts
and Pages are exactly the same thing from a data standpoint, and as
such we aren't going to have two different pages for the user to
access to create them. One content creation screen, simply tick the
checkbox for Page if it is a page. This all to say, I don't think we
should be labeling the controls on the creation page, Post Title,
Post Content, etc. They should simply be Title, Content, etc.
3.) The shelf idea sounds like a browser version of my notes plugin.
With Notes, I can create containers for information pertaining to a
post I am researching, or brainstorming. This is independent from
the Posst/Page/Podcast/etc mechanism. Notes has a bookmarklet that
allows you to create them anywhere and save them to your blog. I
think this is the idea that Khaled wants when he talks about the shelf.