Page structure
Tue, 24/06/2020 - 14:24
I added the screenshot of an internal page in the new website to the
wiki:
http://www.panafril10n.org/wikidoc/pmwiki.html/PanAfrLoc/NewWebsite
This is how a project (PALNet sub-project) will look like:
Main Area will contain:
- description of the project
- latest submissions by members (documents, news, forum discussions,
events, etc.)
Above sidebars:
- A highlighted content item (news/event/..)
Left sidebar:
- PALNet Calendar
- Upcoming project events
- Project news
- PALNet news
- Project documents
- Active project discussions
Right sidebar: (used for different navigation)
- Project links (project news page, project documents page, project
events page, project forum, project gallery, .. etc.)
- User Navigation menu
- Tags used in content items
- if needed: external links block
Footer: (Members area)
- Project members (list with avatars)
- Latest blogposts by project members
If you are viewing a separate content item (say a news item), then the
main area will contain this item only, few of the blocks will disappear
too.
Hope the design is clear for you.
Would love to hear any feedback or questions from you before we start
implementing this design.
»
- Add new comment
- 352 reads
Blogposts
Does this refer to blogposts inside the website, or can we aggregate
from somewhere else? I guess some already blog externally, and it might
be easier to just aggregate with RSS/Atom. I don't think this is a
crucial requirement - just wondering if it is easy to do.
Friedel
yes, these are blogposts
yes, these are blogposts inside the website, but we can definitely
aggregate external blogs, or other websites too.
Dont worry, it's quite easy :-)
few comments
I'm not sure I understand what you mean with "internal page" - do you
mean a public page that is obtained after clicking through from the main
page, or is this a non-public (internal to the team) page?
I'm not sure what the main focal point of this page is. Using text from
your screenshot, I assume that "Keyboard Development" and the
description under that is the main focus point, but it seams a bit
"weak" under the large 'koyagana' heading. Also, I _guess_ that we might
want to link to the most important pages from somewhere close to this
block rather than from a side bar (or at least very high up on the side
bar). I guess some projects might want to have links to fairly static
pages linked to from here as the main "content" rather than blog posts
(I'm guessing).
It is my anticipation that for some teams things like the calender,
events and documents might not be the most important things. For me a
tag cloud is probably not important (I don't know if we'll really
publish that much - but others might disagree.
In general the design is really nice. I guess the two sidebars make it
look a little bit busy/full, but perhaps this can be addressed if not
all these blocks are needed.
By the way, will this be built on an existing CMS? Which one? Hopefully
it will give us really easy translation abilities.
Friedel
Just to chip in on the
Just to chip in on the "private" forums matter. I doubt it will be in
high-demand since we have a mailing list that can be used for matters
that are not necessarily for public consumption. Having a private
forum creates an additional login step before I get to see whatever's
been discussed. A mailing list sidesteps this step because I check my
email anyways (I'm already logged in to email).
Just mentioning this to see whether it makes having the "Organic
groups" module less of a critical feature.
Yes, Views and CCK are neat but again, tilting on the side of starting
simple I'm sure by the time we do need those two modules they'd have
been upgraded for D6.
Paa kwesi
Organic groups is used to
Organic groups is used to have some data/communications private to
subsets of members, according to which sub project you are member of,
the content items displayed to you in some listings will change.
Views is needed early on (any listing you need will require views), but
since that we will only need simple listings then we will probably be
able to start working with the development releases and upgrade as soon
as a stable release is available.
Tying this to an earlier part
Tying this to an earlier part of the discussion, I suggest that the site
run Drupal 6 from the outset. A few reasons:
1) Having just transferred the Kamusi site from Drupal 4.7 to Drupal 6,
I can see a lot of differences in the newest generation. We want many
of the new features, and we don't want to go through the pain of
upgrading later. (blogged here:
http://kamusiproject.org/en/server_changes )
2) Drupal 6 has an absolutely *sweet* tool for L10n. This is reason
enough to use it: http://drupal.org/project/l10n_client
3) There could be network advantages later on of using a common CMS
platform across partners (such as porting L10n data and a single login
system), which Drupal 6 is particularly geared to take advantage of.
Cheers,
Martin
+3 for Drupal 6 :) Paa kwesi
+3 for Drupal 6 :)
Paa kwesi
We are all for working with
We are all for working with Drupal 6 and aware of the built-in i18n support in this new version. Unfortunately, there are some essential modules that are considered the swiss knife of drupal sites which are still not fully ported to Drupal 6. Those modules are CCK, Views, and Organic Groups which we'll be probably using heavily. So we'll keep an eye on them and see how things develop.
Cheers.
--AK
Can you perhaps quickly
Can you perhaps quickly mention what the user-facing functionalities are
that will be unavailable due to these modules not being ready?
Friedel
Organic groups: used to
Organic groups: used to create subsets of the website users, so that
you can limit some content display/edit (and therefore commenting
(discussions).. you have to be able to view an item before you can
comment on it) to members of this group only.
CCK: used for creating complex content types (to be able to add fields
apart from the title and body field, right now we only need it for
creating user profiles.
Views: used for creating lists of content items that match specific
conditions, these views are used to generate pages and blocks
(sub-elements) of sidebars. Examples: a list of the content items that
are documents, a list of the content items that are documents and that
belong to the fonts project, a list of the content items that are
documents and that belong to the fonts project and were published in the
past week, an so on.
Using CCK can be delayed, using organic groups depends on whether the
sub project need it or not (I hope I'll get some feedback on that
matter), using views is a must.
Hope this clarified things a bit.
cheers,
Manal
Yes thanks that did help. In
Yes thanks that did help. In the interest of easier comms, and I think
I echos Paa Kwesi's point, it seems that Organic groups might not be
needed if there is not private area. This comms could be achieved with
sub-project mailing lists if needed or on the general mailing list. The
same for forums, a general one might be valuable but the same comms
could happen in comments to posts.
I don't think we can skip Views though as I would like each project to
be able to publish their specific data.
Since the project and this website will last 3 years I would prefer to
go Drupal 6, but I don't know enough about the technology.
You tell me what's needed or
You tell me what's needed or not :-)
Not having Organic Groups will make things much easier. We will just
use a classification to determine if this content item belongs
to/tagged by/associated with that project or not.
And I agree sub-project mailing lists can be created if needed for
internal sub-project discussions.
So we will keep to the comments on the different content types for now,
and we can enable the forums whenever we want to.
We cant skip views but we can start with the development releases. We
(OpenCraft) would also prefer to use drupal 6 and that's probably what
we'll do.
cheers,
Manal