Nando (Courant Admin) v1 Spec
21 views
Skip to first unread message
Max Cutler
Jun 1, 2009, 2:27:40 AM6/1/09
to courantnews
Hey everyone,
It's been a long time coming, but I've finally finished writing down
the v1 spec for the new Courant admin interface, codename Nando. It is
divided into three areas: conceptual design, interface design, and
technical design. Please feel free to read as much of it as you
desire, and *please* give feedback here on the mailing list.
The interface design portion of the document is a bit barebones, as
Paul and I have determined that it would be best to design the details
of the admin through a prototyping and iterative design process. One
or both of us will be blogging and posting on this mailing list as
prototypes are completed, and we hope you all will be involved in the
process and help make Nando the best it can be.
I will be getting started on the implementation this week, and will be
blogging/tweeting about and committing code as I go. Paul will be
working on the first prototype page, which we'll get into your hands
ASAP. We're going to try to be fully transparent in this process, in
the hopes that some of you will be inspired and want to join in the
fun.
http://www.courantnews.com/files/nando_spec_v1.pdf
I look forward to your feedback!
- Max
It's been a long time coming, but I've finally finished writing down
the v1 spec for the new Courant admin interface, codename Nando. It is
divided into three areas: conceptual design, interface design, and
technical design. Please feel free to read as much of it as you
desire, and *please* give feedback here on the mailing list.
The interface design portion of the document is a bit barebones, as
Paul and I have determined that it would be best to design the details
of the admin through a prototyping and iterative design process. One
or both of us will be blogging and posting on this mailing list as
prototypes are completed, and we hope you all will be involved in the
process and help make Nando the best it can be.
I will be getting started on the implementation this week, and will be
blogging/tweeting about and committing code as I go. Paul will be
working on the first prototype page, which we'll get into your hands
ASAP. We're going to try to be fully transparent in this process, in
the hopes that some of you will be inspired and want to join in the
fun.
http://www.courantnews.com/files/nando_spec_v1.pdf
I look forward to your feedback!
- Max
Mo
Jun 4, 2009, 10:04:13 PM6/4/09
to courantnews
Hey Max,
Read through the spec (skipped the technical section, since I'm not
really up-to-speed with django... yet), and have to say you did a
great job. Very thorough and I was glad to see that you had
rationalized many of the decisions. Made a lot of sense.
Was also good to see some parallels in the workflow piece, between
Nando and what we've been aiming for with Edit Flow (http://
www.copress.org/wiki/Edit_Flow_Project) -- good to know we're both
aiming for similar directions (although different platforms).
Some notes/questions:
Working with InDesign/Desktop Publishing:
I'd imagine XML output would satisfy most needs, since most desktop
publishing programs have XML import capabilities. Adobe has some good
resources on InDesign+XML integration: http://www.adobe.com/products/indesign/scripting/
(though for a true publishing solution, I'd imagine you might still
need a go-between app, that facilitates communication to and from
InDesign and Nando)
Staffer role:
On pg 5: "Staffers are normally placed into one of these departments
as their primary responsibility, which is reflected in their dashboard
and other views." Just wondering if staffers can be placed across
departments? A definite use case in smaller publications.
Key thing I think for any newsroom/publishing software, I think, is
flexibility, and from reading the spec, it looks like you've
definitely got that. Definitely looking forward to the end result.
That's all that struck me as I read through it. Any thing else comes
up, I'll let you know.
Mo
Read through the spec (skipped the technical section, since I'm not
really up-to-speed with django... yet), and have to say you did a
great job. Very thorough and I was glad to see that you had
rationalized many of the decisions. Made a lot of sense.
Was also good to see some parallels in the workflow piece, between
Nando and what we've been aiming for with Edit Flow (http://
www.copress.org/wiki/Edit_Flow_Project) -- good to know we're both
aiming for similar directions (although different platforms).
Some notes/questions:
Working with InDesign/Desktop Publishing:
I'd imagine XML output would satisfy most needs, since most desktop
publishing programs have XML import capabilities. Adobe has some good
resources on InDesign+XML integration: http://www.adobe.com/products/indesign/scripting/
(though for a true publishing solution, I'd imagine you might still
need a go-between app, that facilitates communication to and from
InDesign and Nando)
Staffer role:
On pg 5: "Staffers are normally placed into one of these departments
as their primary responsibility, which is reflected in their dashboard
and other views." Just wondering if staffers can be placed across
departments? A definite use case in smaller publications.
Key thing I think for any newsroom/publishing software, I think, is
flexibility, and from reading the spec, it looks like you've
definitely got that. Definitely looking forward to the end result.
That's all that struck me as I read through it. Any thing else comes
up, I'll let you know.
Mo
Marshall Roch
Jun 4, 2009, 10:31:33 PM6/4/09
to coura...@googlegroups.com
On Jun 4, 2009, at 10:04 PM, Mo wrote:
> Some notes/questions:
>
> Working with InDesign/Desktop Publishing:
> I'd imagine XML output would satisfy most needs, since most desktop
> publishing programs have XML import capabilities. Adobe has some good
> resources on InDesign+XML integration: http://www.adobe.com/products/indesign/scripting/
> (though for a true publishing solution, I'd imagine you might still
> need a go-between app, that facilitates communication to and from
> InDesign and Nando)
Last time I tried that, InDesign CS3's XML import was only good for
creating catalogs and similar documents. You couldn't drag a group of
story elements (headline, byline, content, photo, etc.) from a library
onto the page and then tell InDesign to place a particular XML
document into those elements. Has anyone figured out how to do that,
perhaps in CS4? The new version's docs make it look promising...
> Staffer role:
> On pg 5: "Staffers are normally placed into one of these departments
> as their primary responsibility, which is reflected in their dashboard
> and other views." Just wondering if staffers can be placed across
> departments? A definite use case in smaller publications.
Most of our writers don't have a "home" department and so it'd be
important not to force them to have one. Some editors, even, have
multiple departments, especially when we have vacancies and other
editors fill the gaps.
From the spec, it wasn't clear to me what would prevent the dashboard
from listing the staffer's articles from all sections. For editors, it
should be easy to add multiple widgets that list all the pending
articles in each section of responsibility.
--
Marshall
Max Cutler
Jun 4, 2009, 11:01:05 PM6/4/09
to courantnews
Thanks for the responses Mo and Marshall.
I'll be exploring the InDesign stuff with one of the head P&D staffers
at the YDN in the coming weeks/months, and I'll be sure to publicize
any solution we come up with. I included that in the document to show
the direction that we'd like to see things head.
Regarding placing staffers in departments, you both make a good point
that we need to allow for placement in multiple departments. The
purpose of departments is simply a simple filtering mechanism:
staffers (by default) only see things in their departments on the
various pages. I was contemplating how to handle the managing editors
and EIC roles, and I think the answer is simply to not place them in a
department and therefore they get an unfiltered view of everything
(alternatively, we could have a "special" department that sees
everything). It'll certainly be possible for staffers to look at
things outside their specified department(s), but probably just in a
read-only manner. This is clearly something that will be refined as we
work on Nando, and that's why we'll need input as we start showing off
working code.
For other readers, please continue to post your thoughts. Stuff like
this I hadn't quite thought of, so it's good to get your voices heard.
Max
I'll be exploring the InDesign stuff with one of the head P&D staffers
at the YDN in the coming weeks/months, and I'll be sure to publicize
any solution we come up with. I included that in the document to show
the direction that we'd like to see things head.
Regarding placing staffers in departments, you both make a good point
that we need to allow for placement in multiple departments. The
purpose of departments is simply a simple filtering mechanism:
staffers (by default) only see things in their departments on the
various pages. I was contemplating how to handle the managing editors
and EIC roles, and I think the answer is simply to not place them in a
department and therefore they get an unfiltered view of everything
(alternatively, we could have a "special" department that sees
everything). It'll certainly be possible for staffers to look at
things outside their specified department(s), but probably just in a
read-only manner. This is clearly something that will be refined as we
work on Nando, and that's why we'll need input as we start showing off
working code.
For other readers, please continue to post your thoughts. Stuff like
this I hadn't quite thought of, so it's good to get your voices heard.
Max
Marshall Roch
Jun 4, 2009, 11:35:35 PM6/4/09
to coura...@googlegroups.com
On Jun 4, 2009, at 11:01 PM, Max Cutler wrote:
> I was contemplating how to handle the managing editors
> and EIC roles, and I think the answer is simply to not place them in a
> department and therefore they get an unfiltered view of everything
> (alternatively, we could have a "special" department that sees
> everything).
I wouldn't start adding special cases. Have a many-to-many
relationship between departments and sections, and then you can choose
which sections are a part of each department. For 99% of the cases,
you'd only add one section to each department, but you'd add them all
to the EIC.
A super-department that sees everything wouldn't work for us, since
the EIC controls editorial content and the Publisher controls other
stuff, like business and advertising. So we'd want the EIC to see all
of the content sections and the Publisher to see all the non-content
stuff that's still managed by the CMS.
--
Marshall
Max Cutler
Jun 5, 2009, 12:05:47 AM6/5/09
to courantnews
Just to clarify, by "everything" I only meant in the Newsroom area,
which is where the "departments" system operates. Permissions for
everything else (outside the Newsroom area) will still have separate
granular permissions. I should probably avoid spouting random
implementation ideas before giving them substantial thought.
If you look at the mocks, especially the detailed day mock, you'll see
that the department categorization is just used to bubble things that
are probably more relevant to you towards the top of the pile. The EIC
and other top non-department editors don't need such a demarcation, so
perhaps they just wouldn't be assigned departments altogether. Again,
it's something that's easy enough to tweak and change as we go; most
of the interfaces are going to be iteratively designed as we build
code and get people trying it out.
which is where the "departments" system operates. Permissions for
everything else (outside the Newsroom area) will still have separate
granular permissions. I should probably avoid spouting random
implementation ideas before giving them substantial thought.
If you look at the mocks, especially the detailed day mock, you'll see
that the department categorization is just used to bubble things that
are probably more relevant to you towards the top of the pile. The EIC
and other top non-department editors don't need such a demarcation, so
perhaps they just wouldn't be assigned departments altogether. Again,
it's something that's easy enough to tweak and change as we go; most
of the interfaces are going to be iteratively designed as we build
code and get people trying it out.
Can Duruk
Jun 5, 2009, 12:12:52 AM6/5/09
to coura...@googlegroups.com
First of all, some rather superficial comments about the spec sheet.
It's kind of beyond me why you had to rename the admin part
separately. It's the admin part of the Courant CMS.
"Manage" sounds like managing the internal systems of Nando/Courant.
I'd try to find a better name for the non-content related parts.
As for real comments:
I think you need to prioritize many of the features. The spec sheet is
very comprehensive but there are a lot of things that would be at most
*nice to have* if not just making the thing overly complicated. For
example: users being able to share their widget configs, notifying
people thru PMs. I think having PMs in the system is a double edged
sword; email is significantly more universal. I think a better option
could be something like what Google Groups does; keep things both in
email and in the system. (Or you could wait for Google Wave and
implement that, heh :)
Also, I like the mockups but I think this spec sheet kind of makes it
harder to understand what is going on. I don't see what's going to be
in the Summary Views and Menu boxes in one of the Summary Views. Same
with the Print Version sidebar.
I think you have the right idea with iterative design process but if
you have these kind of detailed mockups, that honestly is hard for a
third party to comprehend fully, you'll eventually end up implementing
random things that you don't really need.
Re: role management, I agree with Marshall about not adding special
cases. A flexible many-to-many should technically cover most of the
cases. Any given special case you add will only make things harder to
maintain.
I'll chime in more as more things come to my mind.
It's kind of beyond me why you had to rename the admin part
separately. It's the admin part of the Courant CMS.
"Manage" sounds like managing the internal systems of Nando/Courant.
I'd try to find a better name for the non-content related parts.
As for real comments:
I think you need to prioritize many of the features. The spec sheet is
very comprehensive but there are a lot of things that would be at most
*nice to have* if not just making the thing overly complicated. For
example: users being able to share their widget configs, notifying
people thru PMs. I think having PMs in the system is a double edged
sword; email is significantly more universal. I think a better option
could be something like what Google Groups does; keep things both in
email and in the system. (Or you could wait for Google Wave and
implement that, heh :)
Also, I like the mockups but I think this spec sheet kind of makes it
harder to understand what is going on. I don't see what's going to be
in the Summary Views and Menu boxes in one of the Summary Views. Same
with the Print Version sidebar.
I think you have the right idea with iterative design process but if
you have these kind of detailed mockups, that honestly is hard for a
third party to comprehend fully, you'll eventually end up implementing
random things that you don't really need.
Re: role management, I agree with Marshall about not adding special
cases. A flexible many-to-many should technically cover most of the
cases. Any given special case you add will only make things harder to
maintain.
I'll chime in more as more things come to my mind.
Max Cutler
Jun 5, 2009, 12:24:57 AM6/5/09
to courantnews
Thanks for your feedback Can.
The separate name is simply a codename, and will perhaps eventually be
just "Courant admin". But for Twitter's sake, as well as a less-
generic name in the code, we chose Nando to make it easier to tell
what we were talking about in different contexts.
I don't like the name "Manage" for that area, but I've yet to think of
anything shorter than "Non-news content management." Rob and I talked
this out to some length and couldn't come up with anything good.
Suggestions are welcomed!
I think I mentioned somewhere in the document that the spec contained
everything that we'd like to eventually see in Nando, but I didn't
want to pollute the document with priority/version numbers all over.
Paul and I have discussed priorities and order of implementation, and
once I think that through some more I'll post it up in the project
wiki and start filing tickets against the desired features. You hit
the nail on the head though, dashboard and PM system are both low
priority items for us now; top priority is the newsroom (workflow
esp.), and then the other content management, and then configuration,
and *then* dashboard and all the other niceties. Part of the impetus
for publishing the spec with everything in it was to see what people
wanted the most.
I'm sorry that the mocks weren't that clear, the tool I was using
isn't all that flexible. Paul is in the process of making the first of
the prototypes, and we'll be posting that for feedback when he has it
done.
Max
The separate name is simply a codename, and will perhaps eventually be
just "Courant admin". But for Twitter's sake, as well as a less-
generic name in the code, we chose Nando to make it easier to tell
what we were talking about in different contexts.
I don't like the name "Manage" for that area, but I've yet to think of
anything shorter than "Non-news content management." Rob and I talked
this out to some length and couldn't come up with anything good.
Suggestions are welcomed!
I think I mentioned somewhere in the document that the spec contained
everything that we'd like to eventually see in Nando, but I didn't
want to pollute the document with priority/version numbers all over.
Paul and I have discussed priorities and order of implementation, and
once I think that through some more I'll post it up in the project
wiki and start filing tickets against the desired features. You hit
the nail on the head though, dashboard and PM system are both low
priority items for us now; top priority is the newsroom (workflow
esp.), and then the other content management, and then configuration,
and *then* dashboard and all the other niceties. Part of the impetus
for publishing the spec with everything in it was to see what people
wanted the most.
I'm sorry that the mocks weren't that clear, the tool I was using
isn't all that flexible. Paul is in the process of making the first of
the prototypes, and we'll be posting that for feedback when he has it
done.
Max
Daniel Bachhuber
Jun 5, 2009, 12:46:37 AM6/5/09
to courantnews
Wow. I started putting together my thoughts and then I got this thread
to deal with. The beginning of my thoughts, in no particular order:
- Regarding users, what they see, and how their permissions are
defined. An idea that came from reading the thread is to handle
permissions and user groups more like tags in the sense that multiple
tags could be added to a person. These tags could either be defined by
department (category in WordPress) or editing capabilities. I would
imagine the tags would just be comma separated values that the
administrator would add to the user's profile (i.e. "sports, opinion,
new") which would mean that the user would have permissions to access
sports OR opinion OR news and see information flows related to each.
Similarly, a user could be tagged with "reporter, editor, admin" to
inherit the permission levels of each. (Mo, make a mental note. We
might do Edit Flow this way too :)
- The distinction between "Manage" and "Newsroom" really don't make
any sense to me at all. Both are about manipulating content and the
permissions related to each; having them separate is just clinging to
some archaic notion of what news content used to be. I'd drop Manage
and put everything under Newsroom. If you could figure out a framework
for managing that content flow such that articles and media work with
it, and then calendar additions and wiki edits could be added as the
applications are fleshed out, I'd say all the more power to you.
- Email notifications are going to be hella legit. I'm not even in a
publishing workflow really at the moment, but we're just waiting to
have them for the CoPress blog. You'll need to have user preferences
for them so that they can choose which type of email notifications
they're going to receive. Commenting makes sense as it relates to
content within the system; I think it's way easier to manage
conversations that way. PMs should just be <
ahref="mailto:add...@domain.org">email links</a> (we'll see how ol'
Google interprets that link)
Going through the mockups now, might have more feedback in a bit.
Looking good, Max! I'm really looking forward to seeing this in the
wild; everyone that's been stuck with an ungainly proprietary CMS up
until this point are going to pee their pants :)
Cheers,
Daniel
to deal with. The beginning of my thoughts, in no particular order:
- Regarding users, what they see, and how their permissions are
defined. An idea that came from reading the thread is to handle
permissions and user groups more like tags in the sense that multiple
tags could be added to a person. These tags could either be defined by
department (category in WordPress) or editing capabilities. I would
imagine the tags would just be comma separated values that the
administrator would add to the user's profile (i.e. "sports, opinion,
new") which would mean that the user would have permissions to access
sports OR opinion OR news and see information flows related to each.
Similarly, a user could be tagged with "reporter, editor, admin" to
inherit the permission levels of each. (Mo, make a mental note. We
might do Edit Flow this way too :)
- The distinction between "Manage" and "Newsroom" really don't make
any sense to me at all. Both are about manipulating content and the
permissions related to each; having them separate is just clinging to
some archaic notion of what news content used to be. I'd drop Manage
and put everything under Newsroom. If you could figure out a framework
for managing that content flow such that articles and media work with
it, and then calendar additions and wiki edits could be added as the
applications are fleshed out, I'd say all the more power to you.
- Email notifications are going to be hella legit. I'm not even in a
publishing workflow really at the moment, but we're just waiting to
have them for the CoPress blog. You'll need to have user preferences
for them so that they can choose which type of email notifications
they're going to receive. Commenting makes sense as it relates to
content within the system; I think it's way easier to manage
conversations that way. PMs should just be <
ahref="mailto:add...@domain.org">email links</a> (we'll see how ol'
Google interprets that link)
Going through the mockups now, might have more feedback in a bit.
Looking good, Max! I'm really looking forward to seeing this in the
wild; everyone that's been stuck with an ungainly proprietary CMS up
until this point are going to pee their pants :)
Cheers,
Daniel
Daniel Bachhuber
Jun 5, 2009, 1:01:58 AM6/5/09
to courantnews
More feedback/ideas:
- Another idea I'm playing with for a couple of projects is the
concept of these comments around changes within the system being
limited to 140 characters. Brevity promotes concise updates, or so one
would hope. The idea is that these updates would then power the
notifications within the system. On the dashboard, you'd have a river
of activity (a la FriendFeed) where you'd have a super to the point
view of the changes being made to content within the system. This
might be worth experimenting with.
- The Dashboard/Newsroom should be the launch point for all activity
within the system. Configuration should either be up in the top right,
or a series of options in the footer.
Technical design is very interesting, but something I'm not qualified
to comment on yet.
Sweet, looking forward to seeing how this progresses. Great job thus far!
--
Daniel Bachhuber
www.danielbachhuber.com
danielb...@gmail.com
cell: +1 971 998 5407
aim/skype/twitter: danielbachhuber
- Another idea I'm playing with for a couple of projects is the
concept of these comments around changes within the system being
limited to 140 characters. Brevity promotes concise updates, or so one
would hope. The idea is that these updates would then power the
notifications within the system. On the dashboard, you'd have a river
of activity (a la FriendFeed) where you'd have a super to the point
view of the changes being made to content within the system. This
might be worth experimenting with.
- The Dashboard/Newsroom should be the launch point for all activity
within the system. Configuration should either be up in the top right,
or a series of options in the footer.
Technical design is very interesting, but something I'm not qualified
to comment on yet.
Sweet, looking forward to seeing how this progresses. Great job thus far!
Daniel Bachhuber
www.danielbachhuber.com
danielb...@gmail.com
cell: +1 971 998 5407
aim/skype/twitter: danielbachhuber
Reply all
Reply to author
Forward
0 new messages