Usecase scenario near completion

I am very happy to announce the Kukuicup-Drupal is almost completed with its Usecase scenario phase. Participants can now view all open activities once they logon and navigate themselves to the "Activities" subtab in the "Myenergy" tab.












User can submit his activity once clicking on the "Submit for Verification" link. This will take him to the activity node itself that was created earlier by an administrator of the system. The activity node would look like the image below.














This is an example of a textfile verification type. The node will display a textfield for the user to submit his answer, and it will also display a larger textarea so that he can input additional comments if he has any. Clicking on the submit button will then submit the answer that will be stored in the database. The screen after the user has clicked on Submit would like like this:
















The administrator of the system can create and monitor the activities as wells as approval/disapproval of the answers submitted by the participants. The administrator can create a new activity by clicking on the Admin tab.
















Clicking on "Here" would take the administrator to the "Create Activity Node" page, which needless to say allows him to create a new activity. An administrator can also view answers submitted through clicking on the "Activity Manager" subtab under the Admin tab.















Here, the administrator can either Award or Decline a user submitted answer. Awarding an answer will take that entry and transfer it into the completed verifications table below. Administrator can also decide to "Undo Decision" which will take the entry back to the pending verifications table.

There are a few more tasks in which we have to complete before finishing our Usecase scenario. One such tasks would include automating the publishing of the Activity Nodes once the publication date has been reached. We hope to complete these tasks and move onto the next steps before the end of the semester.

Enable Ajax Mode in Drupal

I have been trying to work with Ajax in Drupal and I must say it was a cumbersome experience. First of all, even though I could find some online example (source codes), most of them were sort of advanced intermediate level codes and they were really difficult to understand what was actually going on. Moreover, the example codes I based off of never really worked without having to tweak them a little. I found that there was lack of good example Ajax code for Drupal; hence, I decided to provide my solution (that worked) here.

First of all you will need to define what you want in your forms. Basically with Ajax, you would want something that dynamically changes the contents of your form without having to reload the entire page. In my example, I placed a checkbox which will, after it's been clicked, display additional fields titled 'question' and 'answer'.

Here is basically what you will need to add in your hook_form function:

function activitymanager_form(&$node, $form_state) {

function activitymanager_form(&$node, $form_state) {



 $form['textfield'] = array(

     '#type' => 'checkbox',

     '#title' => t('Textfield'),

     '#default_value' => $form_state['values']['textfield'],

     '#ahah' => array(

	'path' => 'activitymanager/autotextfields/callback',

	'wrapper' => 'textfields',

	'effect' => 'fade',

	)

     );



$form['textfields'] = array(

     '#title' => t("Generated text fields for the verification types"),

     '#prefix' => '
"textfields">',

     '#suffix' => '',

     '#type' => 'fieldset',

     );



 if ($form_state['values']['textfield']) {

   $form['textfields']['question'] = array(

	'#type' => 'textfield',

	'#title' => t('Activity Question'),

	);

   $form['textfields']['answer'] = array(

	'#type' => 'textfield',

	'#title' => t('Activity Answer'),

	);

 }

return $form;



}

The Textfield form displays the checkbox itself. The '#ahah' field defines the Ajax behavior. '#path' directory should map to your callback function, which will be called everytime a user clicks on the checkbox. In my case, the callback function is called activitymanager_autoindex_callback. Therefore, the path to the function should be 'activitymanager/autoindex/callback. You must also set the path to your callback function in your hook_menu function as follows:

define(TEST_PATH,'activitymanager/autotextfields');



function activitymanager_menu() {



 $items = array();



 // Setup the initial menu option.

 // yoursite/?q=test

 // if you use clear URLs

 // yoursite/test

 $items['test'] = array(

   'title' => 'Test setup',

   'description' => 'A simple test form.',

   'page callback' => 'drupal_get_form',

   'page arguments' => array ('activitymanager_form'),

   'access arguments' => array('access content'),

   'type' => MENU_NORMAL_ITEM

 );



 /**

  * This is the path in your site to the ajax/ahah callback function.

  */

 $items[TEST_PATH] = array(

   'title' => 'Test setup',

   'description' => 'A simple test AHAH callback.',

   'page callback' => 'drupal_get_form',

   'page arguments' => array (

          // first argument is the callback function.

           'activitymanager_autotextfields_callback'),

           //'test_ahah_cb'),

   'access arguments' => array('access content'),

   'type' => MENU_NORMAL_ITEM

 );



 return $items;

}

The above code is necessary to tell Drupal how it can find the callback function. It is quite cumbersome to add a new entry here everytime you create a new callback function, but it is a necessary step.

Finally here is my callback function:

function activitymanager_autotextfields_callback() {

 // Get form from cache.

 $form_state = array('storage' => NULL, 'submitted' => NULL);

 $form_build_id = $_POST['form_build_id'];

 $form = form_get_cache($form_build_id, $form_state);



 $args = $form['#parameters'];

 $form_id = array_shift($args);

 $form_state['post'] = $form['#post'] = $_POST;

 $form['#programmed'] = $form['#redirect'] = FALSE;



 drupal_process_form($form_id, $form, $form_state);

 $form = drupal_rebuild_form($form_id, $form_state, $args, $form_build_id);



 $textfields = $form['textfields'];

 $output = drupal_render($textfields);



 // Final rendering callback.

 print drupal_json(array('status' => TRUE, 'data' => $output));

 exit();

}

there were some things in this code that I had to tweak to get it to work properly. When I first ran this code, Drupal would for some reason submit the form whenever I clicked on the checkbox without notifying me of it. So if I clicked on the checkbox 5 times, I would end up with 5 duplicate entries in the database. This is obviously not what I wanted, so I began researching what was actually happening. I found out soon that the drupal_process_form function inside my callback function is causing the above behavior. I am yet to understand why Drupal decides to submit the form here, luckily though I figured out a way to work around this issue. I found that the some of the values in $form_state array can be used to change the behavior of drupal_process_form function. I inserted the following code just above my call to drupal_process_form fucntion:

$form_state['rebuild'] = 'notempty';

This eliminated the submit problem I was having. My callback function now looks like this:

function activitymanager_autotextfields_callback() {

 // Get form from cache.

 $form_state = array('storage' => NULL, 'submitted' => NULL);

 $form_build_id = $_POST['form_build_id'];

 $form = form_get_cache($form_build_id, $form_state);



 $args = $form['#parameters'];

 $form_id = array_shift($args);

 $form_state['post'] = $form['#post'] = $_POST;

 $form['#programmed'] = $form['#redirect'] = FALSE;

 $form_state['rebuild'] = 'notempty';



 drupal_process_form($form_id, $form, $form_state);

 $form = drupal_rebuild_form($form_id, $form_state, $args, $form_build_id);



 $textfields = $form['textfields'];

 $output = drupal_render($textfields);



 // Final rendering callback.

 print drupal_json(array('status' => TRUE, 'data' => $output));

 exit();

}

I hope that somebody in the future finds this posting helpful, as adding an Ajax function in Drupal was not an easy task (at least for me).

Problem with Drupal Coding Standards?

If you are just starting to learn Drupal modules, and you are also new to PHP, it might be a good idea for you to brush up on Drupal Coding Standards. I know this sounds kind of boring, but it is a good practice. It is also very important if you intend to share your module with others in the future. This practice will make your code a lot easier to read for others who may wish to modify your module.

Drupal Coding Standards, as you might be able to guess, is basically similar to PHP coding standards. There are, however, some that are very specific to Drupal modules. The coding standards are explained here:

http://drupal.org/coding-standards

I will explain some of these listed above in detail.

Two spaces for indentation is implemented in Drupal standards. No white spaces should follow the end of the line. All line should end with a '\n' character. As opposed to '\r\n' for carriage return and line feed implemented widely in Windows system.

For all the $form[] = array(...); statements, you should format the lines so that it is easier to read. Following is an example from our Activity Manager module.

$form['activitytype'] = array(
'#type' => 'radios',
'#title' => t('Activity Type'),
'#required' => 'FALSE',
'#options' => array('Activity' => t('Activity'), 'Event' => t('Event')),
'#description' => t("Select type of event"),
'#default_value' => isset($node->activitytype) ? $node->activitytype : '',
'#weight' => -4
);

Notice that each element of the array is separated by a new line, while a comma is inserted right before the '\n' character. Also on the following line:

'#default_value' => isset($node->activitytype) ? $node->activitytype : '',

It is important to note that a space should be inserted before and after the '?' character (which denotes 'then'). This is also true for statements like:

$string = 'Hello' . 'World';

where a space should be inserted before and after the '.' which denotes concatenation.

For long lines that span beyond 80 characters should be formatted with new lines to make them easier to read. For instance in our Activity Manager module:

$additions = db_fetch_object(db_query('SELECT activitytitle, activitytype,'
. ' activitystartdate, activityduration, activitypublicationdate,'
. ' activityexpirationdate, activitykukuinuts, activitydescription,'
. ' activityverificationtype FROM {activity_manager} WHERE vid = %d',
$node->vid));

The code above is a good example of a line of code which could have easily gone beyond 80 characters. We managed to resolve this problem by ending the long string with a single quote, adding a new line and concatenating the next piece of line using the same method. The code provided above is a result of the repetition of the steps described here.

Drupal Coding Standards may seem a little annoying at first, but it is actually a good practice that everybody should follow if you are thinking about creating and sharing your own custom module. I would also suggest that you do this early. Learning about the coding standards after writing 2000 lines of code seems that it could be more than a annoyance.

Creating a Drupal Module

Creating a Drupal Module is not an easy task. In my last blog entry, I introduced a method in which to create a very simple Drupal Module. We are now doing something more complicated than a "simple Drupal Module", and I would have to say that initially, it was not a pleasant experience.

As I mentioned before, Drupal needs at least 3 files to run. The .info, install, and the .module files. While most of the important stuff is in the .module file, the three files are almost equally important. The .install file takes care of the database setup. It is basically run only once during the installation of the module. The .module file does almost everything else.

Drupal has an interesting way of handling custom modules. It does so by providing us with _hook functions which we are free to modify. At the same time, however, we are restricted only to modify these _hook functions. It is therefore, important that you first sit and learn what each of these _hook functions are for and how are you supposed to modify them.

Sometimes making more than a module to achieve a task becomes necessary in Drupal. For our case, we have developed an activity module, which handles the creation of activities. We also developed another module called signup that works together with the activity module to enable people to sign up for an activity.















There are also different types of modules in Drupal. The above example "activity manager" that we developed is a node module. As the name suggests, this module creates new nodes and interacts with the database fairly frequently.













The above image demonstrates how a user can fill out all the fields in Activity module to create a node. Each of the field above is a php form in the _form hook function. Once the user clicks on the submit button, the module sends the necessary data to the database to create your new node.














Here is how we made our Signup module. It essentially lists out the activity/events and provides a button for you to be able to signup for them. Unlike the activity module, this module does not produce any nodes. Once the user clicks on one of the sing up buttons, the module first retrieves the necessary information, user name, from the user and saves those information in its own table in the database. This way the module can keep in track of who is signed up for what activity. Also the module allows one person to sign up for more than an activity.

Creating a Custom Drupal Module

I had a little practice learning how to create a custom module for Drupal CMS this week, and I would like to take this opportunity to share this experience with the rest of the world.



Fortunately for us, Drupal provides comprehensive tutorial for creating a custom module here:

http://drupal.org/developing/modules

Though it may seem to you that there is a lot to do here (which is true), it is always a good idea to walk through the tutorial so that you get a general idea of the process of creating your own module. If you are like me, and just want to hurry up and see a module in action, I suggest that you simply copy and paste the code to respective files and place them under the correct directory. I will explain this process more in detail below.

A simple Drupal module needs at least three files: .module, .info and .install files. The .module file, to put it in simple terms, defines the function of the module. It is also where the majority of the codes are located. The .info is a small file that contain metadata information about the modules and themes. Typically the contents of .info files look somewhat like this:

; $Id$
name = "Example module"
description = "Gives an example of a module."
core = 6.x

The above is an example taken from Drupal's tutorial. The name and description fields are required fields. The core field should indicate the version number of your Drupal installation. Drupal 6.x version is used for this example.

Last but not least, you must write your .install file. This file basically contains initial set up codes that are run once while installing the module. Typically (depending on the type of module), this file contains about a dozen lines of SQL query commands that creates the necessary tables in your database.

Overall, creating your custom Drupal module is not an easy task. I hope that the above information helps you to get a general idea. I will certainly post a more detail information once I make further progress with my project.

Managing Activities on Drupal

This is the second week of our current milestone and I am happy to say that we made a big progress forward. After working for a little while on this Drupal system with my team-mate, we realized that it was quite difficult to do a version control. One of the reason why this was so difficult is because we are working with two different operating systems. We faced numerous issues attempting to install the same system on my team-mate's Windows machine. When we finally got most of the functions to work, we have made many changes to the system that it made the version control process so much more difficult.

We then decided to host the system on a remote server. This way, both of us can make changes to the system simultaneously without having to worry about how to get the changes across to the other host. We will just have to make sure that we create back up copy periodically so that we could revert back to an older setting if need be.

After making the above changes, we decided to go ahead and work on the User/Admin activities. We began by searching for an appropriate Drupal module that are capable of this. We came across more than a couple of modules, such as Signup, webform, etc. The Signup module works closely with the existing module called Event, and it enables users to sign up for an event created by an administrator. This module seems to work perfectly well, however, we still need to figure out how to get this to work more closely to that of the mock up designs.

Another module we are experimenting with is called Webform. This module allows to create multiple field types. Using this module, we were able to create field types of an activity. The types that we made include start and end date, publish date, amount of kukui nuts earned, etc. We are still looking to find out a way to combined the above mentioned modules to create a system similar to that of the mockups.

Overall, it is a pleasant experience to be able to work on this system on a remote server. I feel that we are now much more efficient in our development. I hope keep up the work and finish the project by the end of the semester.

Preparing Drupal for Subversion

Have you ever wondered if you could put your web site/application running on a CMS up on a Subversion? That is what I have been working this week and I believe that I have come up with a solution.

The Drupal system, the Kukui cup app, that I have been working on now needs to be under a version control. One of the reason why I am doing this is because I am now working on the project as a group, rather than as an individual. Another reason is so that everybody else in the world can check this out if he/she desires.

My very first approach to version control my system was by putting it up on the subversion repository on my Google Project hosting website. This seemed to me, was the right way to do it at first. It turns out; however, that uploading all of Kukuicup system's content onto the repository requires a large amount of time. So much time that it seemed like my SVN client has stopped working all together. To my surprise, the size of the Kukuicup system happens to be around 21Mb, which I figure accounts for the painfully long upload time. I decided that this was not acceptable.

I realized after some thought that in fact we rarely make any changes to the web contents folder to begin with. The only time we make any changes is when we add new modules to the system or modify any of the CSS files. Therefore, I decided to simply compress the entire web contents folder and upload it onto the downloads section, which can be done with considerably less amount of time. The only remaining problem now is to figure out how to version control the database. I plan to achieve this by simply uploading the MySQL dump file to the repository. This would be useful since we will be making a lot of changes onto the database. The dump file is currently not uploaded to the repository for some security concerns, but I hope to have it up very soon. Following is an image of our Google Project hosting site.



















Following is the link to the project site if you would like to check it out:
http://code.google.com/p/kukuicup-drupal/

Nearing the End of Milestone 2

We are now about to hit the second wall of the semester. Having worked with Drupal for the past couple months, I would have to say that all the hardship and frustration was definitely worth it. I now am very confident at building a website using a CMS and I hope that I sometime in the near future, I would be able to use
what I learned out in the job field.
















The above page is my homepage. I have changed the Login link from having two separate users (user and admin) to a single link, Login. I would also like to mention that the CAS login is now fully functional, meaning that it can now logout properly without caching the previous users' information.

















Above image is an example of an admin user signing into the system. The user is now presented with options modify the content. The user can also navigate to the back-end administration page by clicking on the "Admin" tab at the right hand corner of the menu bar.

















Above is my Google Project hosting website titled Kukui-cup-drupal. Its frontpage now has an example image of the system. I have also added two wiki pages: a developer's guide and a installation guide. In the downloads section, I have added the backup of the database created by a Drupal module "backup and migrate". This module is capable of generating backup copies of the developing site in case we decide to roll back due to an issue. We can also use this backup file to create a brand new copy of the system, which is another reason why the file is available for download.

Building the Dorm Energy Compettion

This week is a continuation of milestone 2. My web-page built on Drupal is certainly improving now that I have added additional functions and pages. Last week I had a lot of trouble getting the slide-show and the tabs-within-tabs modules to work. I am happy to say that both of the modules are now in working order.

Below are some of the pages that I created/improved on.

















One noticeable improvement that I made into this page is the slide-show function. The module is currently set to rotate between 4 images of the UH dormitories. An admin user can easily modify the images by uploading the desired image onto Drupal through the use of Image module.

Another noticeable addition is the CAS login links at the lower right corner of the header section. Both of the links, User and Admin, links to the UH CAS login page where the user can login using their UH username and password.

















Above is the resource page. I modified the sub-menus to appear just below the main-menu so instead of letting it sit on the left-side of the page which clutters it up unnecessarily.

















This is the Energy Hub sub-section of the Resource tab. This page was a quite a challenge with Drupal. It contains two tabs-within-tabs modules which allows the user to switch between multiple nodes without reloading the entire page.
















Above is the Kukui Cup page which simply explains what the competition is about, why should you compete, how to compete, etc.















This billboard page merely describes how you can win the competition, what the rewards are, etc.
















This help page provides the users with a general information about the competition.




















It is important to note that CAS login once again is in working order. Above page is where the user will be directed after clicking on one of the login links on any of the pages.


















After logging in, the user will be redirected back to the homepage, which now contains some additional features such as MyEnergy tab. Moreover, the two login links at the header is now replaced with a logout link.

Milestone 2 Progress

This week is a continuation of our project milestone 2. Our primary objective is to create mockup pages of the initial design that the design team came up with. Below is the design for homepage.















Below is my mockup page of the above design that I created using Drupal CMS.
















I am still unable to implement the slide-show functionality with Drupal. I also noticed that Drupal in general has this boring and uninteresting look (at least for me). In the near future, I would like to work harder on the templates to see if I can make it more eye-catchy and nice.

Overall, I believe that we are progressing quite well, but we may need to speed up a little from now on seeing as how much more work we got to complete for this milestone. It seems that we frequently run into technical issues and we spend too much time attempting to fix that one particular issue. It might be a better idea, though, in the future to ignore some of the issues so that we can get more done in this short time-frame.

Entering Milestone 2

Seemingly long milestone 1 is finally over. Now, we are preparing to enter our next milestone, which will essentially be our development phase 1. We will no longer be creating whatever we want as we did before, but we will now strictly follow Dr. Johnson's new design. This might be a great challenge since not all CMS will be able to do exactly what the project requires. We will certainly be dealing with plenty of work-arounds.

After some considerations, we have decided to keep all four CMS for our development milestone 2. This is taking into account that not all of our CMS could do what it needed to do for the previous milestone. This will mean that we would have to work extra hard for our next milestone to get those CMS to finish up the requirements for milestone 1 and continue with milestone 2. I believe this is do-able.
Fortunately though, the new design that Dr. Johnson had come up with does not look awfully different from what we have been doing. Our site already implements CAS login and is capable of distinguishing admin users from the participant users. What I will have to work on Drupal now is to make it so that once a user logins to the page, he will be directed back to the same page but with more functionalities. My current implementation is that the user will be redirected to a different page once he logs on. I did this so that I could avoid the "Permission Denied" message that Drupal spits out whenever a user is not authorize to view a certain section of a page. I would have to work around this problem though, in order to achieve our goal for milestone 2. This may not be an easy task.

Another requirement for milestone 2 is that we have to create a config file that stores all the information about user authentication. This took me by surprise as I have no idea how to implement this. I will have to research quite a bit to get this to work I assume.

Completing milestone 2 should not be a terribly difficult task, but it certainly will be a step-up from our previous milestone.

Finishing up Milstone 1

We are about to complete the first stage of our project. As I have mentioned before, our goal for this initial stage was to determine which CMS is best suited for the Dorm Energy Competition system, also known as the Kukui Cup Competition.

After some considerations, I have decided to test out Drupal, not only because I was quite unfamiliar with the system, but also because I simply wanted to try something that was new to me. Getting Drupal to work was not easy. I certainly do understand why so many on the Internet complain about this CMS's high learning curve. It does take a lot of patience and effort to really get the hang of this system. Drupal at a glance, does seem a bit underpowered compared to that of the competitors such as Joomla. I was surprised to learn that the initial installation of Drupal does not include modules such as "View" or "Page". These modules are used so frequently that I believe they should be included in Drupal's initial installation. Just the fact that some of the modules, are missing from the initial settings does make this CMS seem a bit more difficult to understand at first.

For the first milestone of this project, I created a basic mock up page to demonstrate the ability of Drupal so that we can then determine which CMS deserves the spot.

The prelogin page was fairly easy to create once I got the hang of using modules such as "page" and "view". The page is basically separated into two sections using the page module, and I inserted the content into each of the two sections with the help of the "view" module. Both the contents, the youtube video and the calendar are simply inserted into the content in html format.

The Kukui Cup page was a different story. For a strange reason, I was not able to simply embed the Google Gadget code into the content of the webpage. Doing so would result in HTML 502 Error. I was not able to resolve this issue unfortunately. I was; however, able to get around this problem by instead embedding the Google Gadget code into the block itself (without using the content module). This caused this particular page to be less flexible and more difficult to work with.

Although Drupal may be difficult to work with at times, its function as CMS is still superb. I would say that we still have quite a ways before deciding on our CMS of choice.

Testing Drupal

Our task last week was to come up with at least 4 CMS that we might be able to use for our Kukui Cop Dorm Energy Competition. We have managed to come up with the following four CMS: Joomla, Drupal, DotCMS, and SilverStripe. After some considerations, I have decided to work on creating a mock up page of Drupal.

Using Drupal I would have to say was very difficult. The user interface of the system was very unintuitive, at least for me, at first and it took me couple of days to figure out how everything works. I would have say though, once I got used to the system, it is actually pretty useful and powerful CMS.

I first started by creating a very simple mock up page of the Kukui cup system with HTML tables and lists. This was easy enough as all I needed to do was to hard code everything into the body of the page. My next task was to figure out whether we can actually use this CMS to do what we need to do for our actual project. It was very simple to figure out how to get the Google Gadgets to work with Drupal. The main problem I had with Drupal was that it took me a very long time to figure out how to insert multiple modules into a single page, i.e. frontpage. It turns out that I needed to use a separate module called pannel to achieve this. After figuring the above out, rest seemed quite straightforward.

I am starting to get used to using Drupal; however, the sheer amount of problems I ran into while trying to get this CMS to work still makes me look back at Joomla. This week's task is to determine our CMS of choice. This maybe a difficult task.

Trying out some CMS

Our team, Kukui Cup Tech is currently on its second stage of the production. We have looked at numerous CMS out there to determine which is well suited for our project. We so far came up with four different CMS: Joomla, Drupal, DotCMS, and SilverStripe.

After presenting our findings with Dr. Johnson, we determined that we should go ahead and create a mock-up page for each of the CMS that we chose. Thus far, we successfully created a mock-up page for Joomla and DotCMS. I would not say that any of the two systems were simple to work with.

Joomla was quite straighforward except that we had to design a template for it work correctly. The initial template design was quite confusing as we had to implement some php code with the html. Working with some of the administrative tools such as article, category, and section managers were quite confusing at first. Luckily, though, we got used to them fairly quickly.

Joomla seems fairly easy to work with and so far we can conclude that it provides all the functionalities necessary for the project. It does provide multiple social networking modules as well as a module for hosting a forum. My thoughts remain the same as those of my previous post's. I am still inclined towards the use of Joomla for the project.

We are still looking to research some other possibilities, including Drupal and SilverStripe. I hope to find the best suited CMS for this project soon.

Starting ICS 414

I am now starting a whole new experience in ICS 414. This time we are not going to be learning new tools so much, but we are actually developing new and exciting web applications. I would like to state that this class would be a whole new experience for me as I only have a little experience building an actual web application for somebody else to use.

Our group was assigned to work on the Kukui Cup tech project. For this project, we will work on the functionality side of the project which includes setting up of CMS (Content Management System). This at first seems to be a rather complicated project, though I hope to learn a lot throughout the duration of the project.

This week's task is to figure out whether which CMS out on the web is well suited for this project. Thus far I looked at Drupal, Joomla, and some of Anahita. I have worked with Joomla before so at this point I am a little inclined towards using Joomla for the project. Drupal seems to work well too; however, I find its user interface unintuitive and difficult to use, although that maybe true only because I have just started using the system.

Through looking at other users' comments online leads me to believe that Drupal, while having a much higher learning curve, generally performs better and can be integrated very well with other tools. Joomla on the other hand, is great for simple tasks such as to manage pages and contents of a site. Joomla also has a much shallower learning curve which makes the system that much more attractive than Drupal.

I would still need to take social networking into consideration before deciding which CMS to use. This would not be an easy task, though I hope to figure out soon.