Web
Brazilian guys, I’m sorry.
But keeping a two language site manually is simply not worthy.
I’m going to write only in English for now on since I write most about worldwide subjects.
Google will be responsible for translating everything for me 😉
There is a new button that will translate without any page reload, which is awesome.
Note: All Portuguese content were already deleted!
just saw the news about the Drupal 7 Release Candidate. I could not be more perplex with the length of its cycle. The code freeze was announced in September 15, 2009, so its more than a year!
I’m perplex mostly because of the nature of this software: an internet application. Because the internet environment changes in an incredible pace, its really counterproductive to stop accepting deep modifications for so long time. NoSQL databases are getting more and more used, JavaScript techniques getting more refined and the whole HTML5/Video is dominating news. Two years to launch a new version is quite a lot.
I have a hunch: Drupal 5 was a true revolution but had a quite short life cycle, coz Drupal 6 was released soon after. I believe several developers got pissed with that as they were forced to make a long conversion process from Drupal 4 to 5 and than from 5 to 6. Drupal 6 took quite some time to actually be used by old sites, because several important modules (Views and CCK mainly) delayed the port to see what direction D7 would take. The result is that Drupal 6 was coined “Drupal Vista: wait for the 7”. This might be forced Drupal core guys to extend the cycle.
The whole problem is now gone since most sites are now ported to D6. But I really believe that was not matter of the short-cycles-that-pressure-developers, but the lack of clear support from project managers. I say that because some even more complex programs are getting big supporters, despite the apparent paradox.
The most enlightening example is Google. Google’s most popular softwares adopted the strategy of the “fast iterations”. The idea is not to aim “quality at all cost” (typical for projects that release when it is ready) but “to fix as soon as possible”. Chrome is 3 years old or so and it is in version 9! The adoption rate is even bigger than Firefox! Android is in version 2.2 already and gaining more and more support of developers. Can you imagine a more complex software with a faster release cycle?
Faster cycles have several advantages:
I think Drupal community still is somewhere between The Cathedral and the Bazaar. They are still in CVS mentality of a centralized control and serialized development of features. We have to make features in parallel, not in series. So no more “feature freeze”, “guys, lets think about the next version… ideas?”. Every time is time to release a new features. It has to create several forks (and not only patches) that will work on each features and, when any of them are ready, commit into mainstream and launch as a new small version, like 7.1, 7.2, 7.3…
One last comment for those that think several people want stability over cutting edge stuff. It’s just to maintain a similar concept used by Ubuntu: time to time a given release will be considered “long term support”. And if Drupal 7.2 is LTS, for example, it could be released several other “features-releases” like 7.3, 7.4 and several “bug-releases” for 7.2, like 7.2.1, 7.2.2, 7.2.3… Fixed time support also gives business and people the right information for a proper planning.
After creating several sites using several CMSes, one single thing still annoys me: the lack of a proper export settings feature. Putting a local testing site in the official online server is always a nightmare, since we have basically try one of the options:
In Drupal world, one of my most admired companies, Development Seed, created both Features and Strong Arm that try to address this, but the lack of broad and ubiquitous support we still feel that we will miss something.
There are 3 types of data that a computer program might have:
Every program that is a platform should provide a Settings API. It would help on 4 big scenarios
There are several situations that we need to maintain a testing site for development new features without testing in the real production site. But time to time, we are satisfied with the test results and we and to apply the modification into the production site. For some business, like 3rd party site development, its the daily job, so its a must to make this workflow faster and painless.
After installing several plugins, its each to get a very unstable site, because they are changing same data. It would be much easier to monitor modifications and find solutions. A settings comparison tool would be great, so we could see what were overwritten.
Platforms, by definition, allow us to build stuff over it. But quite often projects are similar. So why not create a template for other people to use it? For a site builder like Drupal, we could create eCommerce, Blog, Forum templates for an easy deployment. It’s an extraordinary feature for newcomers.
If the program is settings aware, a good extra feature is to apply in a stack. It’s a similar concept of CSS, cascading settings based on specific variables. Imagine, for example, a site about football teams. While the site has a main theme, each team’s page can have one and the users can have a personal one. We could enabled this cascaded settings for each setting.
If we have different content types in a site (ex: static pages, forum pages and news pages), we could have a page to change all settings related to each content type and have a page to change a specific setting of all content types.
As we can see, settings is a very important part in a program. We have to think it with more care to leverage its potentials.
Creating GUI is no easy task. But creating GUI creators is an even more complex task. Almost a nightmare. But the long road walked by GUI creation programs, we already know some things that are good and some things that are bad.
Quite a long time, desktop IDE’s acknowledged that letting developers create GUI with some kind of drag and drop interface were critical. That were because GUI were less and less created by programmers but more and more by designers, that have little knowledge and patience to deal with programming code. It also facilitates the adoption by beginners.
A too designer/beginner driven interface for creating GUI might also not be a good choice. The whole customization and generalization possible by programming is lost. It’s too case-by-case development. It’s not cost-efficient. That’s why a middle term is needed. Some kind a language that is easy enough for designers but programmable. Drupal CMS uses the Form API, a PHP array that will be used to create HTML forms. It’s quite easy to be used by newbies. I heard that QT is preparing some custom language for creating their UI too.
UPDATE (2010-10-03): Qt revealed QML.
Most GUI element have a fixed set of parameters. But sometimes the GUI should be generated on the fly. Developing GUI like this is very trial-and-error. To facilitate the creating phase, its critical to be possible to see it working with some generic data.
The UI 101 rule is to separate the data to the layout. But it is important to let the users change any of them. For example, the user can enter his birth year by a text field or a dropdown list, or some nice JS calendar. This example show how to change the widget, the GUI element. However, the user might need to change the data type. If the birth year was originally text, the user might decide to change it to integer number. The challenge here is to convert saved data. But for most cases, it is feasible.
Developers of both desktop and internet applications are experiencing a quite interesting phenomenon: the same application must have several outputs, like netbook version or mobile sites. With the rise of HTML5, sites now might need multiple different outputs. Also, we must have different outputs when we are creating, viewing or update content. The concept of multiple contexts might be anticipated by the GUI creators.
Integers, float numbers, strings… all developers know these data types. But they know that in some cases it is needed a more complex data types; combination of primitives. Some programming languages have structures and objects to address this idea. But GUIs can also be the combination of multiple primitives. Imagine a “password_checker” GUI element that is, in fact, two form fields that will check if the user typed the password correctly or an “address” element that is, in fact, a group of *country, province and city* fields. Users might be enabled to create and edit these type of custom data structures.
UPDATE (2009-10-05): I just saw an issue posted against CCK module called State of the multigroup module. It has close relationship with this post. Curious is that it is more a hack than a core idea.
Views is the most popular module on Drupal. It’s not a coincidence: the ability to create custom lists on any Management System is critical. Views goes even beyond by creating a display API and enabling export some options to the end users.
I’m, in fact, really puzzled by the fact the Drupal next version, 7, does not integrate it into core. It IS a core module, by any perspective. Several administration pages should be designed as Views from the beginning and the whole DB schema data also should be redesigned to implement integration with that.
But I still see some features that Views could still implement.
The first is external data sources. Today we know that search huge amount of data is no easy task and Drupal core does it poorly. That’s why external programs like Solr, Sphinx are becoming more and more popular among Drupal masters. Views yet does a very little integration with those tools. The whole …8220;query builder" should redesigned to control other data sources. Ideally, it could search on any known data structure. By plugins, it would be possible to search external feeds directly, or some web services’ data, like Twitter, Flickr and Facebook without replicating the whole data locally.
I hope the newly created version 3 implements such abstraction.
