About the target audience. How real the real demo should be.

[sergeysmirnov]

What might be the difference between "Photo Album" as a truly real application and the "Photo Album" as a "real application" we are developing right now?

The very important condition that drives the web project to success is understanding the target audience and satisfy this target audience's needs.

If we were trying to create a "Photo Album" as a competitor to flickr.com, fotki.com, name it, the target audience should be people, photographer and not, who have and want to upload the real photos in order to store them, sort them, print them, sharing them with friends, sale them, slideshow them and so on.

Even our developing "Photo Album" pretend to provide the same functionality, our target audience are Web Application Developers who develop applications using RichFaces and Seam. They will come to the site (or launch it locally) to understand how the blue-print application is working and what programming patterns are recommended to develop the real applications.

I hope, we are on the same page with understanding that our "PhotoAlbum" should look cool, the interface should be predictable and logically correct. Because, if it is not, people will be driven to believe subconsciously that such crappy application is a top that can be reached with the framework and library.

At the same time, we still need to have in mind that our target audience are developer. We should not expect that they will do the same that photographers might do. For example, we do not have to expect that the site will still look great after developers uploaded graphics and left comments. It is highly possible that they will upload pictures from the 'images' folder of they applications and leave "qqqqq"-like comments.

Developers will come to see how things work. So, this information should be available right away like other PhotoAlbum-related features. The good example here is a Booking Demo:
http://demo.flamingo.exadel.com/booking/home.seam .
User can not only registered on http://demo.flamingo.exadel.com/booking/register.seam , but also see the link " What happens when I register?" (at the left column) to read how the registration works.

We should not increase the number of features that might be useful if "Photo Album" were the truly real application. The number of features must be limited to have the explanations of functionality and used patterns are clear and easy to understand. From this point of view the "Booking Demo" is a good example. Even it is about the hotel reservation like expedia.com, it keeps the number of functionality strictly limited and does not expect the real credit card will be entered.

Above, I mentioned that the quality and content of the upload pictures might be far away from the perfect level. So, to guarantee the Wow-like impression from the first flitch, we need to pre-fill the application with "public" albums that user can see visiting the index page. The same content should be packaged in the distribution that developer will launch locally.

The size of the distribution should not be huge. This means that the size of the pictures should not be large. Again, this is a different between our "Photo Album" and flickr.com. Having 3 to 5 Mb photos are important for the printing purpose. We have no reason to allow to upload such huge files as soon as it adds nothing helpful for our target audience.

WDYT?

[pmuir]

"SergeySmirnov" wrote:
If we were trying to create a "Photo Album" as a competitor to flickr.com, fotki.com, name it, the target audience should be people, photographer and not, who have and want to upload the real photos in order to store them, sort them, print them, sharing them with friends, sale them, slideshow them and so on.

Yes, we aren't actually targeting the users of a photo album, but the people who might write such software, as you say.

I hope, we are on the same page with understanding that our "PhotoAlbum" should look cool, the interface should be predictable and logically correct. Because, if it is not, people will be driven to believe subconsciously that such crappy application is a top that can be reached with the framework and library.

For any framework or library having a good loooking demo is important. For a UI orientated framework, this is incredibly important.

At the same time, we still need to have in mind that our target audience are developer. We should not expect that they will do the same that photographers might do. For example, we do not have to expect that the site will still look great after developers uploaded graphics and left comments. It is highly possible that they will upload pictures from the 'images' folder of they applications and leave "qqqqq"-like comments.

Yes, perhaps we should consider a nightly task that resets the database back to the vanilla state?

Developers will come to see how things work. So, this information should be available right away like other PhotoAlbum-related features. The good example here is a Booking Demo:
http://demo.flamingo.exadel.com/booking/home.seam .
User can not only registered on http://demo.flamingo.exadel.com/booking/register.seam , but also see the link " What happens when I register?" (at the left column) to read how the registration works.

The booking demo from Seam is excellent in this regard - it takes you through the whole app and gives you tips. I did something similar with seamdiscs - a series of popups explaining key points.

We should not increase the number of features that might be useful if "Photo Album" were the truly real application. The number of features must be limited to have the explanations of functionality and used patterns are clear and easy to understand. From this point of view the "Booking Demo" is a good example. Even it is about the hotel reservation like expedia.com, it keeps the number of functionality strictly limited and does not expect the real credit card will be entered.

Also, take a look at seamspace from Seam - it has a number of links that just take you to a "Not implemented" page - this is fine IMO.

Above, I mentioned that the quality and content of the upload pictures might be far away from the perfect level. So, to guarantee the Wow-like impression from the first flitch, we need to pre-fill the application with "public" albums that user can see visiting the index page. The same content should be packaged in the distribution that developer will launch locally.

Definitely sounds a good plan - we need to find a source of free photos to use. Can Lex find suitable photos? Or we can talk to James Cobb from JBoss.org

The size of the distribution should not be huge. This means that the size of the pictures should not be large. Again, this is a different between our "Photo Album" and flickr.com. Having 3 to 5 Mb photos are important for the printing purpose. We have no reason to allow to upload such huge files as soon as it adds nothing helpful for our target audience.

Another option is to have a small number of photos in the download, but more in the online version...

[jbalunas]

I agree on all points :-)

So what is the next action here?

*) Discuss the features that will and will not be in - Andrey, Nick, or Sergey?

*) Licensing of contained pictures - Sergey as mentioned can you talk to Lex about this?

*) What and how to "pop-up" information on design decisions? Using modal panes, roll-overs, expanding sections, popups? This is another opportunity to showcase RF!

*) What should accompanying documents contains? What is the docs team working on now?

-Jay

[sergeysmirnov]

The next steps are proposing the set of screens and defining the feature set for the first version of the demo based on the time frame we have set already.

[sergeysmirnov]

Some point we would like to be clarified:

In another thread (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150117 ), LuxSpes is dreaming about the real world application that will teach him "how to deal with master detail CRUD of ToOne, ToMany and ManyToMany relationships". I have nothing against all of those relationships, in general. However, there are not in the list of features for RichFaces. It is just another side of the moon (other side of MVC).
It is not an option right now to use or not to use Seam in the PhotoAlbum application. It is already there. The question is about what is a primary and what is secondary.
I.e.
1. Should PhotoAlbum show and explain the feature of RichFaces as UI library and Ajax framework OR should it be the demonstration how to add UI to the CRUD implemented with Seam?

=============

At the same time, we still need to have in mind that our target audience are developer. We should not expect that they will do the same that photographers might do. For example, we do not have to expect that the site will still look great after developers uploaded graphics and left comments. It is highly possible that they will upload pictures from the 'images' folder of they applications and leave "qqqqq"-like comments.

Yes, perhaps we should consider a nightly task that resets the database back to the vanilla state?

We have a lot of suggestion about adding features that, actually, contradicts with the idea to clean up the new added content.

If the PhotoAlbum application were truly real, it might contains:
* groups with particular interest (fishing, cars, art photo etc) with ability to join the group, sending invitations.
* "friend" relationship (sending and accept invitations)
* Favorites mark for photos
* rating of the photos
* comments for the photos (enabling/disabling, moderating comments)
* sharing photoAlbums (make them public)
* messages between users (CRUD, sending, receiving )
* etc.

In case of nightly clean up (or even weekly clean up), those services have no chance to be alive.
Surely, we have a chance to have a "qqqq" comment and, even, spam content. From other hand, missing all of those kind of features makes the application poorer and far from the reality. So, we need clarification about all this stuff.

2. Do we have to have the "community" feature on the PhotoAlbum application?

=========
As I mentioned above, we are going to have pre-installed set of Album that will be "shared" and available to view by everybody. I.e. the term "public album" means (A) the album that belong to one person, but shared with everyone. The other possible implementation for public album is (B) the album that available for enlarging by others (friends, group, joined people). The B is correlated with the question about "community" features above.

3. Should we stay with plan A or introduce the the plan B as well?


===

The pre-installed albums will be public (shared with everybody). If we add ability to add and share albums by new users, we will open the door for spammer and poor content in online version. If we disable this feature, we reduce the possibility for "community" aspect.

4. Should new registered user be able to share the album with others (friends, group, everybody)?

===

Yes for the previous question brings up the question about administrator as a user role.

5. Should we have administrator as a role of the super user to manage the site options or/and moderate the content?

Having administrator means having a backend part of the application. As soon as we have a fixed date for release, it means decreasing scope for the frontend

===
On the mockups we discuss now ( http://livedemo.exadel.com/richfaces-album/scene2/START_HERE.html ), the albums are plain structure. In the real life, the album might include other albums.
User can have not only the regular album (private or public)?, but albums that can have special meanings like, "recycle", "favorites", "for printing".

6. Should we add the ability to have a hierarchical structure (album in album) or keep the structure plain?

7. Should we add the feature when end user can organize her personal view?

The question 7 depends of time between database cleanup.(nightly cleanup, weekly, never)

=====
Web 2.0 photo sites allow not only store and share, but edit the photos as well (auto level, crop, rotation, adding art frame)

8. Should we add the ability to edit photos?

The 8 is actually a job for RichFaces Ajax and a4j:mediaOutput component, but not only a "cool" feature.

[jbalunas]

"SergeySmirnov" wrote:

In another thread (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150117 ), LuxSpes is dreaming about the real world application that will teach him "how to deal with master detail CRUD of ToOne, ToMany and ManyToMany relationships". I have nothing against all of those relationships, in general. However, there are not in the list of features for RichFaces. It is just another side of the moon (other side of MVC).
It is not an option right now to use or not to use Seam in the PhotoAlbum application. It is already there. The question is about what is a primary and what is secondary.
I.e.

I agree with you and pointed LuxSpes to this topic so that he could add any relevant ideas. The focus of this application is demonstrating and guidance on RichFaces components not on enterprise server side concerns. That being said some of what LuxSpes was discussing is relevant in how complex models are displayed. Hopefully he will share some of this thoughts relative to the photo demo.

1. Should PhotoAlbum show and explain the feature of RichFaces as UI library and Ajax framework OR should it be the demonstration how to add UI to the CRUD implemented with Seam?

As stated primary goal of the demo is to showcase RichFaces. Using seam as the back end in my opinion is optional, but has benefits for users who want to see how they tie together in more complex ways.

We have a lot of suggestion about adding features that, actually, contradicts with the idea to clean up the new added content.

If the PhotoAlbum application were truly real, it might contains:
* groups with particular interest (fishing, cars, art photo etc) with ability to join the group, sending invitations.
* "friend" relationship (sending and accept invitations)
* Favorites mark for photos
* rating of the photos
* comments for the photos (enabling/disabling, moderating comments)
* sharing photoAlbums (make them public)
* messages between users (CRUD, sending, receiving )
* etc.

Some of these are value add that could be very nice, but are not needed in the first release.

In case of nightly clean up (or even weekly clean up), those services have no chance to be alive.
Surely, we have a chance to have a "qqqq" comment and, even, spam content. From other hand, missing all of those kind of features makes the application poorer and far from the reality. So, we need clarification about all this stuff.

The "nightly cleanup" is in reference to the hosted application, not the ones that users can download and build themselves. The hosted version should reset itself regularly to keep it clean for users to explore. We also need to be careful of obscene or other in appropriate content.

I would suggest two running modes that should be simple with Seam. The hosted application keeps session based state so each session will have a clean view. The source code would them allow users to easily change to an application scoped state that users could run locally.

2. Do we have to have the "community" feature on the PhotoAlbum application?

=========
As I mentioned above, we are going to have pre-installed set of Album that will be "shared" and available to view by everybody. I.e. the term "public album" means (A) the album that belong to one person, but shared with everyone. The other possible implementation for public album is (B) the album that available for enlarging by others (friends, group, joined people). The B is correlated with the question about "community" features above.

3. Should we stay with plan A or introduce the the plan B as well?

4. Should new registered user be able to share the album with others (friends, group, everybody)?

All of these "community" related questions are not a priority IMO and could be one of the items marked "not implemented yet"

5. Should we have administrator as a role of the super user to manage the site options or/and moderate the content?

If we add an administrator feature it should use some form of UI that assists in management. This is a "nice to have", but not critical. Many of the seam examples do have an admin concept, and this is used to highlight security.

On the mockups we discuss now ( http://livedemo.exadel.com/richfaces-album/scene2/START_HERE.html ), the albums are plain structure. In the real life, the album might include other albums.
User can have not only the regular album (private or public)?, but albums that can have special meanings like, "recycle", "favorites", "for printing".

6. Should we add the ability to have a hierarchical structure (album in album) or keep the structure plain?

yes

7. Should we add the feature when end user can organize her personal view?

The question 7 depends of time between database cleanup.(nightly cleanup, weekly, never)

What do you think this would look like? Drag and drop?

As for depending on cleanup - I don't have a problem with this. If you look at the various seam examples they all use the in memory DB and everything is reset on redeploy. As you said above this is a demo :-)

8. Should we add the ability to edit photos?

The 8 is actually a job for RichFaces Ajax and a4j:mediaOutput component, but not only a "cool" feature.

I would want to see what this looks like, but my feeling is this is not needed for first rev.

[sergeysmirnov]

On the mockups we discuss now ( http://livedemo.exadel.com/richfaces-album/scene2/START_HERE.html ), the albums are plain structure. In the real life, the album might include other albums.
User can have not only the regular album (private or public)?, but albums that can have special meanings like, "recycle", "favorites", "for printing".

6. Should we add the ability to have a hierarchical structure (album in album) or keep the structure plain?

yes

Is it YES for the first part of the question ("hierarchical structure") or the second on ("keeping plain")?

7. Should we add the feature when end user can organize her personal view?

The question 7 depends of time between database cleanup.(nightly cleanup, weekly, never)

What do you think this would look like? Drag and drop?

Yes, I suggest using Drag-n-Drop is a good use case here.

The 8 is actually a job for RichFaces Ajax and a4j:mediaOutput component, but not only a "cool" feature.

I would want to see what this looks like, but my feeling is this is not needed for first rev.

http://pixenate.com/ is a good examples. I suggest that implementing all of the pixenate.com features is not a point for us. We can implement just a few to show how the mediaOutput and Ajax work.

[jbalunas]

"SergeySmirnov" wrote:


Is it YES for the first part of the question ("hierarchical structure") or the second on ("keeping plain")?

doh - did not finish my thought ;-) Yes we should do a hierarchical structure for albums.

http://pixenate.com/ is a good examples. I suggest that implementing all of the pixenate.com features is not a point for us. We can implement just a few to show how the mediaOutput and Ajax work.

IMO - Lets get a first rev out there and ready to go without this feature. If we have a bunch of time at the end of the release we can look into this more.

[ilya_shaikovsky]

wiki updated according to last discussions.

https://www.jboss.org/community/docs/DOC-12846

[sergeysmirnov]

"SergeySmirnov" wrote:


Is it YES for the first part of the question ("hierarchical structure") or the second on ("keeping plain")?

doh - did not finish my thought ;-) Yes we should do a hierarchical structure for albums.

Jay, we have no common understanding of this feature internally. Could you clarify, please.

Speaking about the "Albums in Album", does it the same as "Album in Folder" or not.

For example, someone has "My travel to Europe" album and "albums in album" are "France", "Spain", "Italy".


Is "My travel to Europe" still an album that can be opened and has all photos of the travel including the ones about France, Spain, Italy

OR

"My travel to Europe" is still an album that contains only photos about Europe except the ones that belong to "France", "Spain", "Italy" albums.

OR


"My travel to Europe" is a Folder-like thing. When user opens it, she does not see any photos, but only the three albums - "France", "Spain", "Italy", she can open and look at.

The answer to this question is important for both model and UI logic.

[jbalunas]

"SergeySmirnov" wrote:

For example, someone has "My travel to Europe" album and "albums in album" are "France", "Spain", "Italy".


Is "My travel to Europe" still an album that can be opened and has all photos of the travel including the ones about France, Spain, Italy

This is basically a pure tagging system - I like this idea, and it is probably easier to implement. The question is can you select multiple tags and if you do what is the behavior? I think being able to select multiple tags is a good thing. So the question comes down to what the logic is when more than one tag is selected. i.e. france AND spain, or france OR spain.

Personally I think france AND spain is the way to go.

OR

"My travel to Europe" is still an album that contains only photos about Europe except the ones that belong to "France", "Spain", "Italy" albums.

This is like a backwards exclusive tag - you only see items that only belong to the tag selected - none that belong to other tags too.

I don't think we should do this one.

OR


"My travel to Europe" is a Folder-like thing. When user opens it, she does not see any photos, but only the three albums - "France", "Spain", "Italy", she can open and look at.

I think that the tag concept is more relevant to how most applications are working today. Although If possible the concept of both folders and tags (#1 & #3) also is nice. But they are separate. If we need to pick one behavior for the first release I would prefer #1.

my $.02
-Jay

[joblini]

...how to deal with master detail CRUD of ToOne, ToMany and ManyToMany relationships

I would be very interested in the above, especially advanced examples of data table usage with in-place updating, addition, and deletion of rows.

Also, examples of extensive Ajax use. For example, using Ajax to re-render only a client area, (not including menus, sidebars etc.), while at the same time supporting bookmarks and the back key.

[jbalunas]

"joblini" wrote:

...how to deal with master detail CRUD of ToOne, ToMany and ManyToMany relationships

I would be very interested in the above, especially advanced examples of data table usage with in-place updating, addition, and deletion of rows.

I agree that these are good features for a demo. I think our next demo will focus more on these types of interactions. As it stands now we are already into development. However I will see what related features we can get in.

Also, examples of extensive Ajax use. For example, using Ajax to re-render only a client area, (not including menus, sidebars etc.), while at the same time supporting bookmarks and the back key.

I think features like this will be much easier in the JSF 2.0 world with some of the changes that just got added to the spec. Like bookmarkable links and others.

Regards,
Jay

[sergeysmirnov]

I think that the tag concept is more relevant to how most applications are working today. Although If possible the concept of both folders and tags (#1 & #3) also is nice. But they are separate. If we need to pick one behavior for the first release I would prefer #1.

my $.02
-Jay

Jay, we have figured out some logical and ergonomic problems with case #1.
If album might include other albums inside and the the photos of the secondary album (#1.a) are visible when user look at the master album (#1.b) then
when user moves photo from the master album to the secondary album the photo remains in the master album (according to the #1.b). So, there is no visual confirmation of the movement.
Then if then user decides to remove the photo believing it is still in the master album, the photo disappears from both master and secondary albums. This is not obvious for the user until she open the secondary album to see the photos in it.

It will be hard to explain to the developers why we implement such logic in our blue-print application.
In real live, the album is a book with photos. Books in the book are possible to imaging, but no so easy to explain how deep might be the hierarchy of the books

I suggest, to support the hierarchy (an the rich:tree as an implementation), we can introduce the "shelf" entity. It will be close to the real life: if user wants to keep several albums together she might put them on one shelf.
Shelf contains albums, albums contain photos. User can move albums between the shelf (with Drag-n-Drop) as well as moving photos between the albums.

WDYT?

[jbalunas]

If viewing album structure is separate from viewing tags this may not be problem.

When viewing an album the user sees child albums as single picture preview of the album (cycle through the images for the preview) along with sibling photo's actually in the parent album. This is a classic directory structure - where child directories show as a preview (identified in some way as different than sibling photos). Windows does this exact thing with directories and photos.

When viewing a tag the user sees all photos that have the specified tag(s).

As I said tagging and album/photo structure are separate items.

Does this make sense?