Following on from my manifesto blog entry, I wanted to discuss some of the changes to structure that Gallery 4.0 introduces and explain why we have made those changes.
This blog entry does get a little technical, but even if you are not a technical person, please bear with me and feel free to skip over sections that are not relevant to you. I feel it is important to explain in detail the challenges faced when re-writing Gallery.
Overview
I want to completely re-focus Gallery and make the media the center of the application. I want users to view the images without being so concerned as to where they belong. I want to focus on organic discovery over being forced to browse pages of user albums or pages of categories.
The Problem
Although competent, it's no secret that the current Gallery has become a little confusing and over complicated. Over the years features and settings have been added too appease a small demand that has undermined the "flow" of the product. I have reviewed a lot of our customer's gallery installations and in most cases a lot of the more complex functionality in Gallery is not being utilised.
For example, the current Gallery allows for very complex permission based hierarchical structures that mixes albums and categories. Programatically, this is incredibly hard to maintain and almost impossible to work with beyond a superficial level.
Consider the following:
- Category A (Global viewing permission)
-- Category B (Restricted viewing permission)
----User Album A (Public)
------ User Album B (Private)
This allows for great flexibility but a severe cost to code maintenance and efficiency. The only way to fetch images that the current user has permission to view is by loading all the categories and albums into memory and iterating over each; testing view permissions and finally constructing a large list of permissible IDs which is passed into an SQL query. This is an "expensive" operation and once you get past 10,000 albums you quickly run into issues with MySQL not being able to parse the query as it is too large. This is a wall and the current model allows for no way around it.
The Solution
Categories and albums are almost alike. They are both containers that can accept uploads. For this reason, I have merged them into a more pragmatic "albums" model.
Administrators can set up "Global Albums". These behave much like categories used to in that you can set them to be containers only or allow uploads. You can restrict access permission based on member permissions much like you do with forums.
Users can create "Albums". These are almost identical to the current user albums in that they can be set to "Public", "Private" or "Friend Only". These are no longer restricted to the 'Members' category or being children of categories. They are created at "root" level and are not included in the hierarchy unless attached to a category.
This creates two different spaces. The Admin defined strict hierarchy and a more social public space.
There are hard rules on user created album use and the software deliberately restricts the freedom of use so that order is maintained and a simple flowing permission model is employed. In practical use, you shouldn't notice these limits but the code is much simpler if you box in their usage.
When creating a user album, you can elect to attach it to a category. When you do attach it to a category, it automatically inherits the permission of the parent category. You will be unable to set it to friend only or private. You cannot attach a sub-album to an album attached to a category.
- Category A
---- Category B
------ User Album X (Inherits permission from Category B)
This small change makes selecting images much simpler as you do not have to consider a dozen different possible permutations. We can now cache permissions with the image which makes selecting them outside of an album a quick and efficient task. This allows us to quickly query "streams" of images without having to learn about their album which frees up what we can do with the interface.
I will begin to reveal more specific interface implementation over the coming weeks.
Please let me know if you have any questions!
By Matt