Bugzilla – Full Text Bug Listing
| Summary: | Consider creating an outlet for Eclipse user interface design | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Chris Aniszczyk <caniszczyk> | ||||||||||||||
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> | ||||||||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | P3 | CC: | aiproulx, b.kolb, b.muskalla, bokowski, bpasero, caniszczyk, contact, Darin_Swanson, dejan, denis.roy, djo, eclipse-bugs, eclipse, Ed.Merks, elias, goran.lochert, gunnar, haeber, irbull, jeff.myers, jeffmcaffer, kelvinc, Kevin_McGuire, konstantin, kpeter, lindawat, litrik, Michal.Tkacz, mik.kersten, mike.milinkovich, Mike_Wilson, nboldt, remy.suen, roger.dudler, thebravoman, Tod_Creasey, tom.schindl, wassim.melhem, webmaster, will.horn | ||||||||||||||
| Version: | unspecified | Keywords: | helpwanted | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows XP | ||||||||||||||||
| URL: | http://mea-bloga.blogspot.com/2007/01/graphicszilla-running-man.html | ||||||||||||||||
| Whiteboard: | stalebug | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Chris Aniszczyk
That's a nice idea, Chris! +1 Yeah, really love this idead! +1 I think it's a great idea - more transparency is always good. However, for this to be successful, we'd need buy-in from the UI and design teams (such as is the case with IPZilla). agreed, there would have to be sufficient buy in from the existing designers if this were ever to materialize... as for more food for thought, I didn't realize WTP had a design contest awhile back with some interesting submissions: http://www.eclipse.org/webtools/wtplogocontest.php It would be great to see what IPZilla is doing, but access is limited to committers and foundation only: https://dev.eclipse.org/ipzilla/. Open but not? visual ui designers as committers? In our own Eclipse-based product we reuse as much Eclipse icons as possible. but sometimes we need to create a new icon, often based on an existing icon. Unfortunately without the original clean hi-res versions there's a lot of low-quality copy/pasting going on. I had a chat with Wayne Beaton during the recent Eclipse Summit Europe where I suggested to make all Eclipse graphics available as a separate download, including the original hi-res versions (if they exist) that are the basis for generating smaller icons and wizard banners. I didn't have time to investigate/push this any further. Maybe this GraphicsZilla/UIZilla could serve as central location for this. So that users would not have to resort to leeching artwork out of CVS as explained at http://blogs.codehaus.org/people/bwalding/archives/000779_icons_borrowed_from_eclipse.html (In reply to comment #7) First, let me point you to an existing source -- updates are in progress here for the UI Graphics specifically: http://wiki.eclipse.org/index.php/UI_Best_Practices_v3.x We have recently re-ignited some momentum to get these updates in place. The skeleton of what is coming is on the page. Discussion page: Add your ideas here! http://wiki.eclipse.org/index.php/Talk:User_Interface_Guidelines In the UI guidelines there will be a package of "common elements" for download. This is not *all* the graphics in Eclipse, but the core concepts to re-use for consistency and to build on when you have new ideas. Regarding "high-res", the resources that will be available here are in true colour so you will have the highest quality we generate. (In reply to comment #7) A central and PUBLIC repository for these images would be good in my opinion. I'm sure this could be integrated into this GraphicsZilla beast ;) I personally have bastardized many Eclipse images and the worst part about it was actually finding the image I wanted to toy with ;) This is a great conversation. We already have a system to organize icons by concept, with formal taxonomy, adding source files and terms of use would be an extra step but well worth pursuing. How can we get this started (or your great ideas about getting it started) Denis, do you have any comments on this as it seems it would be a infrastructure thing if Andrée was able to get permission for this system to be public... Also, this seems like a task that would take some time to do correctly. I'm curious how long IPZilla took from inception to going live. (In reply to comment #11) > Denis, do you have any comments on this as it seems it would be a > infrastructure thing if Andrée was able to get permission for this system to be > public... If you're thinking of having the system Andrée uses installed on eclipse.org, then the software would need to be OSS, as we don't run anything else on the eclipse.org infra. Also, it would need to be linked to the existing Bugzilla database for user authentication, as we don't want to add more usernames/passwords. Other than that, there are other requirements (security, performance, etc...) that we would have to consider. > Also, this seems like a task that would take some time to do correctly. I'm > curious how long IPZilla took from inception to going live. IPZilla is essentially a stock Bugzilla instance with custom UI templates, a custom PHP front-end and absolutely no code customization, so it didn't take very long to implement. The hardest part was the PHP front-end from Committer Tools and the script to populate the users from our bugs.eclipse.org Bugzilla database, according to active committer accounts. The implementation and testing took dozens, but not hundreds of hours of my time (hard to guess), spread over the course of one Quarter (of a year). (In reply to comment #5) > It would be great to see what IPZilla is doing, but access is limited to > committers and foundation only: https://dev.eclipse.org/ipzilla/. Open but not? The motivation behind this is explained on the IPZilla proposal page: http://wiki.eclipse.org/index.php/IPzilla hi Denis It depends if we want to do this quickly or not. We could provide a link to a standalone search tool to quickly let developers search for icons to get to the important part of this process. I don't see the point of logins as this is simply a search tool. A request tool would be separate and could be part of the existing zilla tools, with maybe a longer term integration, but as you mention that could take months. Without the integrated workflow, we could regard this as being similar to the policies for ipzilla. Such facility might be incorporate to Eclipse. And we could be discussing visual ui design patterns integration to the mix, rather then providing the basics: searchable published graphics. +1 Created attachment 65088 [details]
Data set
Find included the data set and the graphic library for Eclipse Projects and Eclipse Tools-Projects created by the IBM UI Design team, as it stands today.
I'd be happy to provide guidance in the creation of a search tool and perhaps a request tool.
All graphics included are already under the Eclipse Public License V1.0.
Created attachment 65090 [details]
Eclispe Projects graphics library
Created attachment 65098 [details]
Eclispe Projects graphics library (continued)
Created attachment 65099 [details]
Eclispe Projects graphics library (continued)
Created attachment 65103 [details]
Eclipse Tools graphics library
Created attachment 65104 [details]
Eclipse Tools graphics library (continued)
Thanks Andrée, I will make the UI Working Group aware of this fantastic contribution. Denis, is there someone at the foundation would be willing to host something like graphics.eclipse.org where this content could be browsable? I could set up www.eclipse.org/graphics in 2 seconds flat. Does that work for you? Now that Europa is out of the door and the UI Best Practices working group is getting active again (see http://dev.eclipse.org/mhonarc/lists/ui-best-practices-working-group/msg00182.html), it would be nice if this great inventory of Eclipse icons would get some more attention. Is there any chance of getting comment 21 and comment 22 done anytime soon? I sent an email to the UIBPWG and the email fell on deaf ears. If you want to send another email to them about this issue, that would be great. Sometimes it takes quite a bit of pestering ;) (In reply to comment #23 and comment #24) The task of creating a browsable inventory of UI graphics is not UIBP workgroup item. It's something the foundation or the Eclipse Platform UI team would need to provide. In comment #22, Denis offered to set this up under www.eclipse.org/graphics. This would be great Denis. Thank you. Once ready, I will add a link to the Resources section of the UI Guidelines: http://wiki.eclipse.org/UI_Best_Practices_v3.x#Resources ++1 for this idea as I think that it is a great way to encourage consistency and quality for plug-ins that build on the platform. We've kept the Photoshop files for Mylyn icons in CVS from the beginning, but if it makes sense to move these into a common area I would be happy to do so as long as there is a mechanism for me to get commit rights for this area. I'm not sure if it's best to keep the icon sources with the project or not, but on this bug report it seems that the consumers of them would like them to be in a single area. Based on my experiences it's most important to have the the SDK and WTP icons available since they are some of the most exemplary and high quality ones, but other projects' icons could be useful to make available as well. (In reply to comment #25) > (In reply to comment #23 and comment #24) > The task of creating a browsable inventory of UI graphics is not UIBP workgroup > item. It's something the foundation or the Eclipse Platform UI team would need > to provide. True its not up to the UIBG WG and its highly unlikely the platform UI team has time to build this. We think its a great idea though. Since the goal here is for the community to be able to make re-use of existing graphics, it seems the community is well motivated to create browseable access to this content. (In reply to comment #27) > (In reply to comment #25) > > (In reply to comment #23 and comment #24) > Since the goal here is for the community to be able to make re-use of existing > graphics, it seems the community is well motivated to create browseable access > to this content. So what we have here is agreement that (a) this is a good idea, (b) it is not the role of the IUBG WG to do anything about it and (c) it is not the role of the Platform UI team to do something about it. And to add to this list, I don't feel that it is the role of the EMO staff to do this either. So this is a perfect example of where some volunteerism from the community is required to get something done. If no group steps forward, this just not going to happen. Since this is such a "good idea" should a new workgroup be created to address this problem? I'd assume since this is such a good idea, we would have possible volunteers in the community to make this happen. On a side note, I think this is a perfect fit for the UIBP. What better way to help with best practices by providing an easy way to access graphics from Eclipse projects as a first step. However, maybe another group makes sense in this case. I don't think this is an issue that requires yet another working group. The initial icon database is provided by Kim, Andree and their team. We need someone to administer it and manage the infrastructure that we need to support and add to that database. Sounds to me like this is something the EMO should handle. As a start, I'd suggest that those who care a lot about this subject should get together to figure out what the requirements of the technology are and provide at least a broad strokes design of the solution. Chris, you should be one of those people :) With that in hand we can talk about who should/could do the work because we'll know better what the work looks like. At present it could be anything from a bugzilla repository to cvs projects with a certain structure to a web UI backed by a MySQL database. Each of those possibilities makes a huge difference in scope of effort and who has the technical ability to implement it. The UIBP group would then be keen to discuss the outcome of that discussion on one of our calls. Again, we care about the subject, will help to contribute content, but there are just no development resources available. Fair enough Kevin, I have a lot of love and ideas to give to the Eclipse community, time is always a limiting factor for me (believe it or not!). I'm hoping someone more qualified from the graphics/ui community in Eclipse would step up and move this idea forward. Anyone else have cool ideas ;)? Oh as a side note, if this is a REALLY important to committers, you might want to push your local committer representatives to raise this issue at a board meeting where there is power to instruct the EMO to do things :) The only problem I see is that we haven't really defined "what that thing is" and this is something the UIBPWG might help with. What do they envision as a nice solution for this problem? Ed, as the committer rep covering the Markham Rd/16th Avenue area, please consider yourself pushed to bring it up at the board meeting. The EMO needs to take initiative to make this happen. We need the infrastructure/money/will/resources to make it happen. Working groups and the community can help to make it successful and the EMO needs to host/manage it. Wassim, I don't really need so many votes in that slum area that you referred to. I've already bought all the votes I need there. Just kidding. :-) Like everyone else, I think this is a great idea. I just don't think we can dump this in the foundation's lap and expect them to solve the problem for us. I'm quite sure that we will get support for whatever good solution we as a community arrive at. So I agree with Kevin's comment, we need a proposal for how best to organize the icons and then try to create as little additional infrastructure as possible around it. I've added Nick to the CC list because he and Neil often accomplish amazingly cool things with just a few scripts so they might be able to provide a little bit of help and guidance. It would seem good to just reuse bugzilla and define some type of file structure in CVS that's conducive to browsing. I could imagine that there might be a significant number of folks in the community that would get a kick out of designing icons that end up widely used... It sounds like all that's required is a mechanism to post content and a mechanism to search/browse for content. Given the success of IPzilla, why not create a GUIzilla (affectionately called "goo-zilla") as a first pass so people can submit content & search for it? We'd need a standardized workflow (read: custom front end, like IPzilla has) to ensure the content is properly described w/ sufficient meta to make it findable. Then, in a Phase ][, we could concoct a better search engine than the default bugzilla one to do better querying, if necessary. Or, to go in a perhaps simpler direction... is there something OSS out there like picasaweb or flickr we could use to centralize community contributions, and make them searchable? I discovered recently that all the images I upload to my blogspot blog are automatically added to a picasaweb album -- we could do something like that for GUI contributions, too. Or, even simpler... what about just using the existing Wiki or a new one specially designed for images only? Either way, you get upload, search, browse, and image description. http://wiki.eclipse.org/Special:Imagelist Why reinvent when you can reuse/repurpose? ;-) Its great to see all the enthusiasm but let me try again: Some small group of people need to spec out the requirements for this. They need to do that somewhere other than in this bug report since this isn't a good medium for idea refinement. That group needs to be self-organizing. The UIBP group is not that group (although some its members could be). When they have those requirements, they should post them back here. There is a lot of enthusiasm, so a good start might be if someone took the initiative to send an email to those on the bug who seemed the most keen. The UIBG group would be happy to spend one of our by-weekly sessions going over the output to help refine it etc. We all think "it" is a good idea, but I am betting I'm not alone in not being at all clear on what "it" is. Without knowing what "it" is, nobody, not the EMO, not the UI platform team, not the UIBG WG, can be of any help. Its just not going to go anywhere. This, in my mind, is the best path to success available to us. as a point of infrastructure interest, just use images.google.com to do the searching. All you need is an area of the eclipse.org site that is Google scanned and some way of associating keywords with the images. Then qualify any search with site:eclipse.org/cool-images (whatever) and away you go (to whatever "it" is) (which by the way I fully support, it, I think, ... uhhh, depending on what, uhhh, it, is...) (In reply to comment #34) > The EMO needs to take initiative to make this happen. We need the > infrastructure/money/will/resources to make it happen. > > Working groups and the community can help to make it successful and the EMO > needs to host/manage it. I just love the expectation that the EMO is an infinite pool of resources capable of implementing every good idea. I will reiterate what I said before: no. I can imagine providing some (very) small amount of infrastructure enhancement to enable this, but if it is not a community-led and community-maintained initiative it will not happen. We just do not have the resources. There are other activities of higher priority. And, in any event, putting the EMO at the centre of every Eclipse community activity is just plain wrong. I am not suggesting that this issue is the most important issue in the universe and that the EMO should drop everything to implement it. However, I do think the EMO is expected to be involved in hosting it and managing it, when/if it happens. This filibuster makes me really sad. I agree with Kevin, I'm not really sure what "It" is. It seems to be either a system to help UI designers track / design Eclipse graphics with more transparency, or a system to help other committers / contributors / users browse and search existing images. I imagine these would be two different beasts to tackle (although maybe the system is really both). Why don't we start a wiki page to track requirements and see where we are at after that. (I would create this, but i'm not really sure where it goes or maybe it already exists). Maybe this would make a good SoC project next year. :) OK, great minds think alike. ;) Somehow we have to get out of this circle. http://wiki.eclipse.org/Eclipse_UI_Outlet (In reply to comment #40) > However, I do think the EMO is expected to be involved in hosting it and > managing it, when/if it happens. Hosting it is clearly the EMO's responsibility. Managing it seems unlikely, although that term could mean many different things. The point is that every time the EMO takes over "management" responsibility for something, it requires a long-term resource commitment from us. And it takes away an opportunity for people in the community to get further involved in Eclipse. We have to be very cautious about which obligations we collectively assign to the EMO. Thanks Mike. We are on the same page. Before we define the word "management", many people on this bug report are trying to define the word "it", which is reminiscent of Bill Clinton trying to define the word "is" :) well at least we know what knowns are unknown! clearly we are fit to run a country! As Mylyn graphics guy I am going to share my very simple and concrete requirements for this, in the spirit of Nick's suggestions for reusing existing technologies considering Mike's points about resources. Others could have different requirements, I just want to communicate what would facilitate the way that I have been consuming graphics design for the past couple of years since others might be in the same boat. As a producer of graphics content: * I need to make the binary (e.g. GIF, PNG) and source (e.g. Photoshop, Illustrator) files for icons available to the community so that others can reuse them. Binary is important because it can be reused by any tool. Source is important because it preserves things like transparencies and facilitates composing variations that reuse the great visual language that we have from Platform. What I have been doing from the start is checking all icons into CVS. As a consumer I need: * An easy to browse and search repository of the binary icon content of Eclipse projects. * Access to the sources of common elements used in Eclipse UI design. Here's how I'm currently meeting my needs: 1) For source refer to the common elements: (e.g. http://wiki.eclipse.org/UI_Graphics_:_Design_:_Common_Elements and Kim's other posts) 2) For binary use the OS's ability to search filenames and show the results as images: used to search through plug-ins, now I use the icon set attached While I think that a searchable graphics DB like the one proposed could be really cool, I'm not sure that I would use it because the graphics tools I use make it easier to work when all the images are on my filesystem, so I would rather be downloading a Zip like the one attached. It would be great if this Zip were generated automatically every once in a while, e.g. via a script that runs after each Europa update. In terms of the sources, all I need is for the wiki page linked above to stay up-to-date, and if other projects are creating similar "common elements" it would be great if they could share them on wiki or elsewhere so that they can be accessed if needed. On top of Mik's requirements, my original dream here was to have a system contributors that aren't committers could help out with. For example, if a project needed an icon, there could be a request filed and possibly filled by a community member (or a graphics team if the project has one). I don't know if people realize it, all the icons in Eclipse projects and the especially Platfrom don't materialize out of nowhere. There are talented UI designers, interaction designers, artists, etc... that are behind these things and I think it would be nice if things were a bit more transparent. Having access to just the source graphic files would be nice for some things. It took me forever just to find a blank folder icon.... :P Added my requirements here: http://wiki.eclipse.org/Eclipse_UI_Outlet#Contributions (In reply to comment #47) > have a system contributors that aren't committers could help out with. You mean like the system we have for Logo Contests, like bug 175200 or bug 154906? Seems to me we already have a system for this -- bugzilla. And as Mik points out, we already have the Wiki for housing the up-to-date binaries. Do we really need something else? I don't know... we my have it... However, would we like to do customizations in bugzilla like we did for IPZilla for this? I could imagine all graphics being tracked in bugzilla, however, we have some limitations as most graphical designers aren't committers which limits what they can do in bugzilla. I'm just happy the discussion is going on again. Maybe one of the graphical designers like Andree, Kelvin, or Kim Peters may want to comment on what they envision. It makes sense to use bugzilla and make any customizations that would be needed for this tool. If it helps, we can start by going through our internal request tool (as well as the search tool) and see what could apply in UIzilla. (In reply to comment #49) > I could imagine all graphics being tracked in bugzilla, however, we > have some limitations as most graphical designers aren't committers which > limits what they can do in bugzilla. How so? They can submit them as one would submit a patch. Going the bugzilla route is an advantage in this way over using CVS, since (1) its easier for those who are new (2) CVS requires commit rights (and voting and etc) but bugzilla doesn't. In response to Chris in comment #49: I know you are now taking requirements comments in the http://wiki.eclipse.org/Eclipse_UI_Outlet page, but I'd like to add my thoughts here on what I think "it" could be and what is already available. Pardon the verbose text. I've tried to be comprehensive. A. GraphicsZilla -- what "it" could be: 1 - A searchable repository of all UI graphics in Eclipse, including all contributions going into a release. I agree with Andree in her comment #13 on the short term goal best being a searchable repository that is open, not gated by authentication. She has made a mondo drop of all the platform and tools graphics that we design for, including the meta-data that we associate with these artifacts in our own internal repository. This drop can seed the initial eclipse.org search tool, with the ideal goal of having others' graphic contributions added to reflect the graphic content initially of Europa, next Ganymede and so on. If this could be automated, even better (in support of Mik's comment #46). As Kevin calls out in comment #31 and Ed in comment #35, the requirements need to be determined and it looks like this is well underway on the wiki page link above. The IBM UI Design team can provide content and help influence the UI for input and results, but we cannot create it. It would be great if we could use an existing technology, such as google images, as Jeff and Nick have suggested, so that you can get the benefit of the images in place within the search results. If CVS can offer this, great, but it seems more cumbersome. As for where it will live, Denis's proposal of www.eclipse.org/graphics sounds good. 2 - A single source for core icon elements from the platform. Common elements are already supplied in the UI Guidelines. I don't see the value in repeating this information. Instead, simply creating a linkage between the GraphicsZilla and the UI Guidelines would do the trick. 3 - A place to request graphics to the community, if there are designers in the community able to donate their time and skills to this kind of ad hoc request. A bugzilla inbox could be set up for the graphics community. Honestly, I don't know how much of a graphics community exists but this could be the bud of one. It should be said that our team cannot take on gaphics requests for the Eclipse community at large; we just don't have that kind of personnel available or resource commitment to Eclipse. B. Existing resources 1 - The UI Guidelines provide "Common Elements" to use as is, pull out parts, or reassemble in different ways. See: http://wiki.eclipse.org/UI_Graphics_:_Design_:_Common_Elements. These are composed common images. There is also the core elements AI and PSD files that include a number of "primitive" or core elements that are not composed. See: http://wiki.eclipse.org/UI_Graphics_:_Design_:_Consistency_%26_Reuse. 2 - Source icons - As said in comment #8: The resources available in the guidelines are in true colour so you will get the highest quality we generate when you download any of them, be it the Common Elements PSDs or the output GIF files. Our own working files are essentially 'flat' for our own efficiency -- icons on a background -- so you are not gaining much by getting the PSDs. 3 - As a short term solution, until we have a searchable repository or in case that does not come to pass, I will provide links from the "Resources" section of the guidelines to the zips that Andree has posted. I will break the links into project and tools. Others are welcome to add their graphic zips to this page manually. C. UIZilla -- what this "it" could be: I think this is something more than the GraphicsZilla, which seems best focussed on UI Graphics, starting with a searchable repository for all Eclipse-based icons, wizard, and welcome graphics. A UIZilla could cover a much broader set of things, including UI Graphics, UA, and UI Design, as well as other graphically oriented content such as animations, logos, tours. For requests, bugzilla seems aptly suited, but some prefixes noting design type would be useful. Have there been any developments in this area? It's a great idea! The attached zips are very helpful, but an up to date online version would be very useful. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. I think we can assume this will not happen without someone to champion the effort. |