History: AdminUIRevamp

! 2021 New Project
Here ((Unified Admin Backend))

! 2014 Tiki13

The admin UI is getting better and better, still I struggle to find some things that are not included in the icon based admin sections. 

There is the default application menu shipped with tiki, that you can include in modules, make it visible only for admin, etc, but it is covering too much imho and also all those scrollings and clickings... :)

The idea is to clean the admin UI a bit more and to simplify some actions for admins. This would be done using a bootstrap navbar, see screenshots below.

Note: Currenlty the menu options reside in a normal Tiki menu that is included in the navbar. But I think for the admin UI there is no need to be this flexible, so I would go for "hardcoding" these menu options into the navbar of tiki-admin.tpl

What do you think about this approach?


Access related stuff (users, groups and permissions)
{img fileId="737" thumb="y" rel="box[g]"}

Content related stuff (depends on what is enabled, links bring you to content listing, eg: tiki-list_blogs.php, tiki-list_articles.php etc)
{img fileId="736" thumb="y" rel="box[g]"}

Generic (or General?) stuff: transversal features
{img fileId="735" thumb="y" rel="box[g]"}

Tools – technical stuff for admins
{img fileId="734" thumb="y" rel="box[g]"}

Preference filters
{img fileId="732" thumb="y" rel="box[g]"}

Admin notification icon (list of things that require admin attention, not worked out fully, could be like notifications in the future)
{img fileId="733" thumb="y" rel="box[g]"}

Wizard button (to start various wizards)
{img fileId="738" thumb="y" rel="box[g]"}

Search
{img fileId="739" thumb="y" rel="box[g]"}


!- 2007-2008
!!Meetings
__Proposal__: 21:00 GMT Monday December 10th, 2007 for an audio and/or chat and/or a [http://www.cardmeeting.com/|cardmeeting]

Meeting notes: ((AdminUIRevamp20071210))


!!Background information
Tikiwiki has more [http://doc.tiki.org|features] out-of-the box than any other CMS or groupware package out there. Experienced Tiki admins know how great and efficient it is. All features are just a few clicks away. No need to find, download and install 3rd party modules/plugins. However, the admin panel is huge and confusing in some places. So you do need to hunt to find the right checkbox. For new admins that just want a wiki or just want a blog, they could be tempted to use a simpler package.

Historically, when Tikiwiki developers add new features, they often add the option (because it's one of our ((3 Rules))) somewhat randomly in tiki-admin.php?page=features  For example, "Calendar manual selection of time/date" should be in tiki-admin.php?page=calendar instead.

We had a [http://tiki.org/TikiFest198|TikiFest and a CardMeeting session] on this topic in June 2007. Some work has been done here in Tiki 1.9.8 (vs 1.9.7) but it was more to solve the biggest issues than a true clean up.

Many things were improved in 1.10 vs 1.9.8  
*Most icons were updated to nicer ones
*Many aspects were cleaned up
*Assign permission is faster.
*etc

But we can still do better!


!!Solution
Re-work the admin panels to be easy, fun & intuitive for new Tiki admins. These changes must be fairly quickly added to BRANCH-1-10 (before the freeze) and before too many screenshots are made for the Tiki 1.10 documentation.

With new panels and a proper re-organization of the current admin panels, it should make it pretty obvious for devs to add their new options in the appropriate place (and for admins to find them!). It is OK to have a setting in more than one admin panel, when it's relevant to both. However, the admin only needs to set it once.

The focus here is on making it intuitive to administer which is a distinct focus than ((Edit User Interface Revamp)), which is how to make it more intuitive to participate to content creation. The focus is also different than  ((Infrastructure Revamp)), which is to improve install/upgrade/backup/security. AdminUIRevamp ideas assumes that install went correctly. Of course, some individual tracker items can overlap in more than one project.

This will include
*Re-organizing things in admin panels
*Icon work
*Adding tips and links to documentation
*Changing some of the default settings to more intuitive settings (what most people would use)
*[http://tiki.org/Glossary|WYSIWYCA] (if someone uses Tiki just for blogs, it should be simple, without extra options/features)
*Hiding some more advanced/rarely used features in something like "expert mode"
*Possibly some interactive wizards to setup some features.
*Whatever you think is needed.


People who spends some time on training, documentation, forums and support know where new Tiki admins have questions. New admins are also great to give feedback on what was difficult to understand. If you don't have coding skills, don't worry. If you have a good idea, someone will code it!


!!People
*Luci
*Marc Laporte
*Dthacker
*You?


!!Steps
#Decide how we will coordinate (hopefully dogfooding trackers)
#Recruit contributors & facilitate input.
#Scanning all tracker items on the wishlist and identifying & prioritizing the ones that relate to this project.
#Get as many as possible of the items done, in order of priority (see below importance vs easiness).  

!!How to determine priorities?
There will always be more ideas & feature requests than people available that can work on them. In this context, how do we choose what to do first?

!!!Let's try 
#To involve more people so we can get more done.
#To focus on things which affect the most people. So let's fix things in transversal features before things that are specific and not everyone uses. ex.: user administration vs tiki maps.
#Pick all the low-hanging fruit first (Do the easy stuff)
#To be pragmatic
#To make optional a feature that should have been optional before

!!!Let's avoid
#Trying to be perfect. There are diminishing returns to investing more & more time on something. [http://en.wikiquote.org/wiki/Voltaire|Perfection is the enemy of good enough] (Voltaire). It will always be possible to improve later on. That's the beauty of a unified code base like Tiki.
#Being dogmatic about "how it was done before". Yes, we want to respect the past. However, in many cases, things were done without much thought and the original author would be just as happy or even happier to have done it the way we'll do it now.
#The temptation of adding new features. The goal here is to re-organize what we already have. It's a low-risk operation. Adding a simple option (checkbox to activate/deactivate something in an existing feature is ok though)

!!Timeframe
||2007-11-23|project launched
Early December|Audio conference call of luci, marclaporte and whoever is interested to review all tracker items and discuss priorities
December & January|implementing the chosen ideas
||


!Wishlist
To add things to this list, you can [tiki-view_tracker.php?trackerId=5&show=mod|create a new tracker] (you must be logged in) or edit an [tiki-view_tracker.php?trackerId=5|existing tracker item]. In both cases, please make sure to __click the checkbox "AdminUIRevamp" project.__

Please base your suggestions on how Tiki 1.10 is done. You can test 1.10 [http://110.tiki.org/|here] and get your copy [http://dev.tiki.org/Download|here].

All items on this list will be evaluated, but not necessarily treated.
{LIST()}
   {filter type="trackeritem"}
    {filter field="tracker_id" exact="5"}
    {filter categories="160"}
    {filter field="tracker_status" content="o OR p OR c"}
    {sort mode="modification_date_ndesc"}
    {pagination max="50"}
    {OUTPUT(template="table" pagination="y")}
        {column label="Subject" translatelabel="y" field="subject" sort="tracker_field_subject" mode="raw"}
        {column label="Category" translatelabel="y" field="category" sort="tracker_field_category" mode="raw"}
        {column label="Feature" translatelabel="y" field="feature" sort="tracker_field_feature" mode="raw"}
        {column label="Importance" translatelabel="y" field="importance" sort="tracker_field_importance" mode="raw"}
        {column sort="creation_date" label="Created" field="created"}
        {column sort="modification_date" label="Modified" field="modified"}
    {OUTPUT}
    {FORMAT(name="subject")}{display name="tracker_field_subject" format="objectlink"}{FORMAT}
    {FORMAT(name="category")}{display name="tracker_field_category" format="trackerrender" default=""}{FORMAT}
    {FORMAT(name="feature")}{display name="tracker_field_feature" format="trackerrender" default=""}{FORMAT}
    {FORMAT(name="importance")}{display name="tracker_field_importance" default=""}{FORMAT}
    {FORMAT(name="modified")}{display name=modification_date format=date}{FORMAT}
    {FORMAT(name="created")}{display name=creation_date format=date}{FORMAT}
    {ALTERNATE()}^{TR()}No results{TR}^{ALTERNATE}
{LIST}

!!Screenshots of ideas
((AdminUIRevamp Screenshot Ideas))

!!Broad ideas for the future
Next steps could include work on improving the ((Install|installer and profiles)). Ex.: Not for profit association portal, Classic corporate website, Wiki-centric community, Forum-centric community, Blog, etc   Nicer admin panel + better Site Identity + better installer/profiles: I think could help a lot :-) Maybe we could maintain the definitions of profiles in wiki pages to make it easier for community contribution.