Here is my vision for the G2 user interface. As we design and implement the user interface we should keep these goals in sight.
- Gallery 2.x will have a UI that makes people say WOW.
- The interface will be intuitively easy in all languages.
- The interface will get the job done without a lot of clutter.
- The interface will be slick and seamless with attractive graphics.
- The result will be standards compliant (XHTML, HTML 4.0, etc).
- The interface will be so intuitive that little or no online documentation will be required (although we'll provide localized, online documentation just to be sure).
- In a perfect world, we'll do everything using stylesheets and dynamic layouts and avoid using tables. (see ALA: Tables are Dead to get an idea of what I mean).
- The interface will be easy for users to modify and customize to suit their own specialized needs.
Posted: Fri, 2003-04-25 00:09
Posts: 45
Have you made any thought of opening up Gallery to be able to communicate against Flash?
So the UI would be all made in Flash, but the backbone (thumbs, search, comments, etc) would G2 take care of. With a XML communication solution.
I know it's quite far out, but if G2 had some way of communicate with external applications, I think that would be a great feature (I guess this would be more like a plugin, maybe?)
Posts: 89
As soon as you start relying on resources like Flash you enter into a world of problems with client side compatibility. That's the only major downside that comes to my mind. In an application like this you want the project to be as non-dependant on the user as possible.
Posts: 45
I guess this feature as I am talking about should more come under some sort of RPC plugin for gallery, instead of as a UI consideration for Gallery, witch will be XHTML/CSS based.
I just suggest that there are more than one way of making and thinking of a UI.
One apparent one is HTML/CSS, but it could be as well be in Flash, java (applet) etc.
One question though: The UI of G2 will still be part of the core, or would it work more as a plugin/module?
Posts: 4
well, I suppose one COULD build the new Gallery UI with XML Output, and then use XSLT for the template-sys. Then it would be easy to have a Flash Client connect to it and all sorts of output formats would be possible (PDFs e.g., for printing).
On the other hand, apart from a LOT of additional work, there would be hassle with the serverside XSLT-processing.
I don't know about flash XML-processing, but wouldn't it also be possible for a flash application to parse XHTML (as that also just an xml application)?
Tell me more, hawkin :wink:
Posts: 7994
The first round of the G2 UI will be HTML only and will be part of the core offering. It should be fairly easy to add an XML interface that provides access to the G2 API.. this will allow us to integrate a Flash front end.
As a matter of fact, a friend of mine has written up a Flash front end that I think we'll be
able to adapt to G2 without too much difficulty. It uses XML parsing so we'll have to retrofit it to use the Gallery API but that shouldn't be too difficult. This will fit into the G2 pluggable layout architecture relatively easily, but probably won't happen until post G2.0.
G2.0 will not be doing XML/XSLT. We'll be using the Smarty templating engine to do our template transforms instead. I recommend that you install G2 and examine the existing templates to get an idea of the direction we're headed in.
Posts: 3474
To answer this:
G2 works as a bunch of "modules" (even the "core" is considered a module), each of which uses <!-- BBCode Start --><A HREF="http://smarty.php.net/" TARGET="_blank">Smarty</A><!-- BBCode End --> templates to control the layout. The layout of these bits, and the interplay between them, will be the crux of the UI team's job. Deciding how to display search results or user comments effectively, how the image adding/editing will be structured, developing the flow of "Config. Wizard"... these fall under the heading of "UI". In other words, the UI team's job isn't to decide that Gallery should use Arial 10-point font and a chartreuse background colour with mauve highlights. (But of course, having G2 look super-spiffy out-of-the box will be an important UI job)
On top of the "modules", whose templates will specify the layout of specific elements, there will be "themes", which also have Smarty templates. The themes won't alter the UI layout much, rather focusing on the fonts and photos and colours... kind of like "skins" I suppose. The themes will be more easily user-configurable than the modules. Here's where the equally imporant "Arial" and "chartreuse"-type decisions will play out.
As modules are added/created by others, it will be necessary to write more templates, presumably starting by getting the new bits to match whatever ends up being G2's "default" look-and-feel, but also allowing Gallery's themes to do their work.
-Beckett (
)
Posts: 7994
Excellent summary, Beckett!
There's one more piece to the puzzle. G2 has something called "layouts" which are modular pieces of code that specify how the photos appear on an album page. Each album has a specific layout assigned to it. You can have a layout that shows photos in a grid (say, 3 rows and 3 columns just like the Gallery 1.x default), or you could have a layout that shows the large version of one photo and thumbnails of all the other ones in the album beneath it. Or above it. Or in a little slideshow. Any layout that you can conceive of can be codified into a layout module.
Each album can have a single theme and a single layout assigned to it, so you can mix and match them to make something attractive.
Posts: 89
I like this idea Bharat!
Is the goal to have the layout defined by the album's owner, admin or both?
Posts: 7994
The layout and theme are part of the album properties so they're chosen by whoever has edit permission on that album. Typically the owner and any site admins have that permission (though a site admin could theoretically take that permission away from the owner!)
Posts: 11
i never needed flash to make impressive sites. people are still surprised what you can do with plain (d)html. css is a great help of course but even with css the trouble starts already depending on which version you decide on.
xhtml compliant, barrierfree cross-browser development is a real nightmare.
there was an excellent article on this in the last c't nr 8.
for related links on barrierfree sites check: http://bobby.watchfire.com/bobby/html/en/index.jsp
xhtml and css validator sites are well known so I won't mention those here.
While it is debatable if a "barrierfree" G2 design is needed, xhtml and css compliance is a must, imho. Also, compliant sites will perform well in any browser. G2 might not be for "lynx" though (people still use this text based browser? yes!) :wink:
Ihad.
Posts: 3474
Using my website log as an example, at least 97% of my visitors in 2003 were using a reasonably compliant browser (*not* Netscape 4.x, which is almost extinct).
-Beckett (
)
Gallery and lynx. Hmm. Not unless we could generate ASCII pics!
<!-- BBCode Start --><TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Code:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><PRE> _____ _____ __ __ _____| |
| | | __| | | | | | |
| | __| |__| |__| | |__|
|__|__|_____|_____|_____|_____|__|</TD></TR></TABLE><!-- BBCode End -->
Posts: 11
hey, actually a g2ascii module would be cool. script interprets the pixels and spits out ascii art :cool:
I bet this has been done before, somehow, somewhere.
Ihad.
Posts: 7994
Yep, there's a library called "aalib" that will do this for us. I've been toying with the idea of making a G2 module around this that would create ultra-low-res versions of images to use as placeholders :smile: I've always wanted to do that.
Posts: 3
How about a PDA or WAP Friendly module for G2
Posts: 14
Just a quick heads up. I don't know much about templating systems (I only just started using Smarty), but I did come across this post (http://radio.weblogs.com/0103807/2003/06/13.html) the other day which seems to find a significant performance difference between Smarty and Smart Templates.
Posts: 154
has anyone looked into this? smart template versus smarty? seems they are onto something.
Posts: 7994
Yes. I've reviewed it. I doubt that we're going to see a significant speed increase in porting to SmartTemplate, and it would probably set us back a month or two on our final release date. Don't believe the hype on a website
Posts: 113
Hahaha ... ASCII Ultra-low-res — I love it. The ultimate in accessibility. *grins*
But back to the original topic - the Gallery 2 UI - has any work been done so far to make a "Wow!" interface with ECMAScript (aka. JavaScript 1.5) and DOM/CSS? Is that a direction you want to explore? I mean, without JavaScript, we can still do great CSS effects, but with JavaScript ... well ... anything is possible (and reproducible). ;)
Posts: 328
CSpotkill, we have some JavaScript here and there to help our our administrative UI, but I think we can do much better. Having a layout entirely based on javascript is a possibility, but this isn't really a priority number one. We have the slider layout that already uses some JS stuff, take a look at it. Maybe you have an idea of a new javascript-based layout?
Other than that I think we might need some improvement in several administrative UIs to make them easier and faster to work with. JavaScript can surely help on some dynamic tasks. But first we should be make some usability decisions, so that we can have an overall well thought system. Maybe you can bring in some suggestions, as you have a good experience with what is possible. Go through the whole G2 administrative tasks, see what is inconsistent, what you think could be done better, etc. Discuss your ideas with us in this forum (open a new thread) and let's see where we can go from there.
Posts: 1
Usability issues:
I have written a much more modest gallery program in Python, and I have looked all over your Gallery site. I am not sure how well several of my user efficiency design goals are included in your work:
If I take a session of digital pictures, I generally want to process them all, and there could be many more than 10. My pet peeve is having lots of extra GUI actions when I am doing something repetitive, like entitling and commenting on a batch of pictures. In my version, the user merely adds optional titles and comments under the names of each of the picture files while looking at a preliminary gallery. The program provides an initial skeleton text file, with all the picture file names already included and marked in the same order as the preliminary gallery.
You refer to text files for 10 picture descriptions. This is a step in a good direction. Still, if you stop at ten pictures, there is the question of which ten pictures. Does a user have to explicitly enter all the file names as well as the descriptions? That seems like unnecessary overhead.
Another feature that I included is that the picture names are by default changed to be based on the human-entered titles, rather than my digital camera's meaningless names. This (and picture rotations) makes the previous picture description text file be out of sync, so I regenerate the text description file, including the new consistent descriptions and file names. This means further editing of the description file is trivial. From the brief mention of your description text files, I cannot tell if you include an analogous feature. Do you? I strongly encourage it.
It looks like these features would be included in your Gallery Remote module. I commend you for making it easy to work remotely, and upload the results automatically at the end, without ongoing user interaction. Even with a fast connection, that can be a great time saver.
Posts: 7994
I agree that we should have features like this. Would you please file them as feature requests on http://sf.net/projects/gallery for us? Thanks!
Posts: 32
I totally agree, I think I mentioned something like this before in another thread. But easy uploading of mass pictures is important... for me 100-150 in an upload is more the norm then 10, so anything to make this simple and streamlined is a great idea.
Cheers,
Quentin
Posts: 7994
We do allow you to upload many, many files at once using the upload applet, Gallery Remote, or some of the other upload methods. I also just added a new feature that lets you add captions to 9 images at a time to speed things up. I basically reproduced the G1 captionator as a starting point -- we can add more features to it as we figure out what's appropriate.
Posts: 6
my main input would be that for those of us who want a cleaner look, or who are embedding the gallery into our websites existing design (eg wordpress users) DONT WANT A SIDEBAR. a tool bar above might be an alternate solution so people can still get access to certain features without it taking up a quarter of the screen.
Posts: 32509
you could create a theme that does that...
and you should take a look at the wpg2 theme and other non-official themes. if you don't want a sidebar, remove all blocks from the sidebar and it will disappear.
perhaps you still want to show a search box somewhere, and the item actions as drop etc. all you have to do is create your own theme or customize an existing one.
Posts: 6
valiant, customising wordpress themes is easier than customising g2 themes, and considering wordpress took me a week, that's saying something
this topic is about good UI and good UI offers the options of NOT having sidebars, none of the themes included with G2 offer a workable alternative to the sidebar and that is down to an inflexible UI and bad foresight in theme design.
rather than dumping all UI issues onto users and expecting them to magically become experts in the most incomprehensible CSS i've ever tried to make sense of. those who ARE developers, and those who ARE assigned the task of making Gallery2 a desirable product need to deal with UI issues themselves.
Posts: 32509
lou77, it would be nice if you were a little less aggressive, there's no reason to shout. After all, we've spent thousands of hours making G2 the product it is. And a lot of that time was also spent on UI and how theming could be simplified.
The G2 UI is very flexible. Just because we don't have a GUI for everything, doesn't mean it's not possible.
Once there are some docs for themeing and how to place the blocks where you want etc., you'll see how easy and intuitive themeing in G2 is.
It can't be so hard, given that there already are user contributed themes shortly after we changed the whole theme system for beta 4.
I agree that the notion of "sidebar blocks" won't cover 100% of what users want, but it's perfect for 90%.
What you want is just an additional blocks group, something like top blocks or bottom blocks.
Meanwhile you can either wait until there are docs available, use one of the existing themes, try your luck customizing it, or choose another software.
Posts: 1
Hiya
I specialise in advanced Flash UI's, having worked for companies like EA, Microsoft & Cisco to name a few.
I have already built a detailed Coppermine UI in Flash and am about to commence a Flash UI for Gallery 2. Having already built most of the necessary componets required on previous jobs the area that'll slow me down is the MySql-querying logic / order (ie. which tables contain what fields and what they all mean)
Any assistance / guidance to documentation here would be greatly appreaciated.
KR
Richard
ps. Want to help? Mail:
with your area of expertise!
Posts: 32509
richardmax, that sounds cool
We have a google summer of code student also working on a flash based theme for G2.
As to your question:
When interacting with G2, you should use the API. the chance that the information that you want is not covered by the API is relatively small. But if that's the case, you can query the database with $gallery->search($sql, $params);
you should start by copying the matrix theme (the default theme) into your own directory (see cloning a theme) http://codex.gallery2.org/index.php/Gallery2:Themes.
Then you can place your flash object in the theme.tpl file or so.
take a look at the existing themes on how to get the information / in what variables the album / photo information is.
modules/core/classes/GalleryCoreApi.class exposes most of the methods you'll ever use and modules/core/classes/GalleryTheme.class is the parent class of all themes.
Posts: 12
@valiant
I am using WPG2 and have been looking to do this (remove the Gallery2 sidebar in WordPress only) for a while. Now that you've pointed out how it can done, I took a look at Site Admin -> Image Block. I'm new to all this and I'm having a little difficulty comprehending even definitions of blocks; as well as working out how to implement the instuctions there at Site Admin -> Image Block
Can you expand a little on how I can proceed from here or just point me the available documentation. Thanks
Posts: 16504
There's not much on documentation, just check out the Documentation link in the upper-right corner. There is more added every day.
Valiant, was referring to blocks located in Site Admin > Themes > <YourTheme> Remove any blocks there from the Sidebar and you'll be good to go.
However, your question isn't really related to this topic as it's a discussion of the UI design and not how to use it. So if that doesn't help, please create a new topic.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 12
nivekim,
Sorry about the topic irrelevance. Just a bit over-enthusisatic when I saw a possibility of solving a particular issue ;-)
Thanks for the block thing though. It did give me something to look at. Now I have other questions concerning that!
Posts: 16504
No problem. Ask away, just in a new topic
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 19
There is now a working flash interface for gallery2 called FG2Interface.
See my post at:
http://gallery.menalto.com/node/58957
For more details, visit my website:
http://www.tamlyncreative.com.au/fg2interface/