You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Joachim Dreimann <jo...@wandisco.com> on 2012/01/31 18:07:23 UTC
Bloodhound UI basics
Hello all,
I've spent about two weeks coming up with a general idea of how to
improve the UI for the first release of Bloodhound.
I'm really looking for feedback here on the direction this should go.
My thoughts so far are:
1. Search should play a major role in navigation.
2. Content should be shown in a pane larger than half the screen width
on the left.
3. Activity relating to the content is shown on the remaining width on the right
(this is essentially Trac's timeline feature with context-specific
filters applied).
4. The minimum width we should design for is 1024px,
because that covers every device down to small tablets in
landscape mode (including the 7" Kindle Fire).
5. It should be possible to create tickets everywhere without leaving
the current page.
That may look something like this:
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.png
I'm trying to stick to three basic principles in all design decisions:
* Next steps are obvious.
* Bloodhound values users time.
* Users decide what's important.
The basic page setup would stay consistent throughout all of the
Ticket system in Bloodhound. The Wiki and Source browser won't benefit
so much from the Activity stream, in fact they both already have good
methods to deal with that type of information.
What do you all think?
- Joe
Mockup files here (these will be updated regularly:
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.bmml
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/assets/bloodhound_logo.png
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/assets/header_footer.bmml
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Feb 1, 2012 at 6:36 AM, Joachim Dreimann
<jo...@wandisco.com> wrote:
>
[...]
>
> On 31 January 2012 22:23, Olemis Lang <ol...@gmail.com> wrote:
>> On Tue, Jan 31, 2012 at 12:07 PM, Joachim Dreimann
>> <jo...@wandisco.com> wrote:
>>
>> [...]
>>
>> cool !
>> Below I mention a few ideas , mainly focused on how to get this
>> implemented in the theme itself
>> ;)
>
> That's great actually, I think we should go straight from these rough
> drafts to implementation. I'm more happy to refine the design in html
> than to come up with things that may be easy to mock up but difficult
> to implement.
>
:)
[...]
>>
>>> 2. Content should be shown in a pane larger than half the screen width
>>> on the left.
>>
>> good to know . I was thinking of using a 50% - 50% layout initially
>> :$
>> 66% - 33% should be ok ? or maybe some combination of fixed & relative
>> width (i.e. using height & max-height) will be better ?
>
> Yes, 66% + 33% width will be fine to start with. My thinking here is
> that content should always be your focus, Activity is just a view of
> what happened to the content recently.
ok . I'll put all those pieces together and try to update the theme
for you to take a look
;)
> Once we have something up and running we can have a play around with
> different fixed/relative widths for either half, I'll happily get
> involved with that.
>
cool !
>>> 3. Activity relating to the content is shown on the remaining width on the right
>>> (this is essentially Trac's timeline feature with context-specific
>>> filters applied).
>>
>> once I reviewed previous mockup I was thinking of considering activity
>> to be yet another widget in the dashboard ... afaics the idea now is a
>> bit different than that ... isn't it ?
>
> Yes, I actually found the Activity view useful in all parts of the
> ticket system. For example the Component view:
> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_componentView.png
> ( Mockup http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_componentView.bmml
> )
>
> This is consistent across the dashboard, project, version, milestone,
> component and ticket views.
Ok I get it ... ;)
I've taken this into account when «sketching» the dashboard and all
other stuff .
> In some future version this would also be the natural place to show
> activity graphs (see .png above), but that's not needed for our
> initial work.
>
agreed ;)
>
>>> The basic page setup would stay consistent throughout all of the
>>> Ticket system in Bloodhound.
>>
>> ... so my aforementioned impression of including the timeline as part
>> of the dashboard is not valid anymore , isn't it ?
>
> As above, this applies everywhere in the ticket system. The Dashboard
> is only special in that it pulls in data relevant to the user from
> everywhere - all other screens just provide a narrower focus.
>
ok
>>
>> if that's the case , options to get this done are as follows :
>>
>> 1- implement component outside core (e.g. side-by-side with
>> plugins migrated from Trac-Hacks ;) that detects that both
>> ticket and timeline systems are enabled and , if this is
>> the case , inserts the timeline (i.e. using ITemplateFilter ... afaicr )
>> 2- implement such behavior and package that component in
>> the theme itself
>> 3- modify genshi templates in core components to include timeline
>> and/or implement that idea in core distribution
>> (maybe in TicketModule itself, but maybe others ...)
>>
>> ... beware of the fact that timeline and ticket modules are separate
>> entities in Trac .
>>
>> why do I mention options above ? So as to know if the theme should
>> be changed or something else needs to be implemented
>>
... btw . IMO choosing one of aforementioned options is a very
important aspect we need to think about before start doing something
*serious* .
>> [...]
>>>
>>> Mockup files here (these will be updated regularly:
>>> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.bmml
>>> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/assets/bloodhound_logo.png
>>
>> ... about logo file ; it'd be nice to have a similar picture in
>> transparent background ...
>
> I'd go one further and say that we need a vector graphic of the logo,
> at least of the hound.
+1
[...]
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet 12:35 Jan-20
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Feb 1, 2012 at 7:17 AM, Gary <ga...@wandisco.com> wrote:
>>> ... about logo file ; it'd be nice to have a similar picture in
>>> transparent background ...
>>
>> I'd go one further and say that we need a vector graphic of the logo,
>> at least of the hound. I've never met the person that created the
>> logo, does anyone else know whether we can still get this? If not we
>> may go down the road of tracing it..
>>
>> - Joe
>
>
> Well.. I believe that this logo is the transparent one:
>
> http://people.apache.org/~gjm/apache_bloodhound_logo.png
>
> I think that there are some original psd files that might be able to provide
> the logo in a number of layers. It is probably worth those also being in the
> repository.
>
... if not in the repos , IMO it makes sense to publish it somewhere ... ;)
thnx in advance !
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet 12:35 Jan-20
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Gary <ga...@wandisco.com>.
>> ... about logo file ; it'd be nice to have a similar picture in
>> transparent background ...
> I'd go one further and say that we need a vector graphic of the logo,
> at least of the hound. I've never met the person that created the
> logo, does anyone else know whether we can still get this? If not we
> may go down the road of tracing it..
>
> - Joe
Well.. I believe that this logo is the transparent one:
http://people.apache.org/~gjm/apache_bloodhound_logo.png
I think that there are some original psd files that might be able to
provide the logo in a number of layers. It is probably worth those also
being in the repository.
Cheers,
Gary
Re: Bloodhound UI basics
Posted by Mat Booth <ma...@wandisco.com>.
On 1 February 2012 11:36, Joachim Dreimann
<jo...@wandisco.com> wrote:
>
> I'd go one further and say that we need a vector graphic of the logo,
> at least of the hound. I've never met the person that created the
> logo, does anyone else know whether we can still get this? If not we
> may go down the road of tracing it..
>
> - Joe
I think Ben at WANdisco took over Warren's graphic design role -- he
might have the source Photoshop files, etc. Might be worth asking him.
--
Regards,
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Feb 1, 2012 at 9:10 AM, Mat Booth <ma...@wandisco.com> wrote:
>
> On 1 February 2012 13:29, Olemis Lang <ol...@gmail.com> wrote:
> > On Wed, Feb 1, 2012 at 7:11 AM, Mat Booth <ma...@wandisco.com> wrote:
> >> As y'all may know, the user interface in Trac at the moment is built
> >> using Genshi template. Would using bootstrap involve ripping out that
> >> dependency?
> >>
> >> I would be for this if it meant increased speed rendering the UI. As
> >> awesome as Genshi is, its design does not lend itself to super-fast
> >> template processing. [1]
> >>
> >> [1] http://genshi.edgewall.org/wiki/GenshiPerformance
> >>
> >
> > -1 for removing Genshi . Trac is tightly coupled to that templates
> > system . There was a discussion about this subject in ( trac-dev |
> > trac-users ) MLs months ago and I go -1 for that . Maybe at a later
> > phase ... and honestly I don't recommend doing so (but final decision
> > involves much more reasoning by many people paying attention to some
> > other details ;) .
> >
> > ... just my $0.02
> > ;)
> >
>
>
> So it's not a replacement UI template engine then? Just trying to
> understand how Bootstap fits in.
>
>
Instead of providing a yes / no ... I think we (that includes /me as
well ;) should read this thread @ trac- ML [1]_ before moving forward
.
I do can tell you that the relationship between Trac & Genshi
templates is not just limited to rendering the templates provided the
data . It's also about stream filters , and a bunch of other features
that should have at least a candidate substitute in the *new*
templating system ... due to the fact that a lot of plugins rely on
this to get some things done (e.g. I was thinking of using such
*hacky* to render activity feed at the right of dashboard ;)
Subject is open AFAICS after reading [1]_ .
PS: my -1 above may change provided that there's more information
regarding the subject, implications and specific migration steps ;)
PS: PS: There was another relevant thread about this subject some time
ago involvin mako , jinja, chamelon.genshi ... but I could not find it
right now :-/
.. [1] trac 0.11 / Genshi performance
(http://www.gossamer-threads.com/lists/trac/users/42130)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet 12:35 Jan-20
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Joachim Dreimann <jo...@wandisco.com>.
Well said!
Also, Bootstrap and Google Prettify play nice together:
http://twitter.github.com/bootstrap/base-css.html#code
Just to highlight a point again that was only mentioned briefly before:
As Bootstrap is a quite common public framework with great
documentation we can make it much easier for new and current plugin
developers to provide a consistent look & feel.
On 1 February 2012 15:54, Jeremy Whitlock <jc...@gmail.com> wrote:
> Hello all,
> There were too many thread to respond to inline so I'll just address things here.
>
> 1) Bootstrap is just a CSS framework with a few very lightweight JavaScript plugins built on top of jQuery. It is not a templating engine nor is it going to have any impact on what we use on the backend to generate the markup sent to the client. That being said, we could easily update the current Trac templates to generate markup that is suitable for Bootstrap and move on. I have a good bit of familiarity with Bootstrap so once we start working on this, I'd love to help.
>
> 2) Geshi filter's performance is a concern that we should address sooner rather than later. Based on my understanding of how it's used, we could remove the dependency on it by having a real UI framework like bootstrap in place. Since all of the UI stuff is handled by Bootstrap, the backend templating system would not have to do as much as it does now which might make its importance diminish. I know that trying to get something out quick likely will not leave much room for a templating system overhaul now but I think the problem Geshi is solving on the backend could be alleviated by using a good framework on the frontend.
>
> 3) I know Geshi does more for Trac than just help render it's frontend, it also helps do syntax highlighting of the sources being displayed in the repository browser and such. I'm not an immediate +1 on removing it but again, I have a suggestion for a client-side solution that will help make our backend much leaner and performant: Google Code Prettify (http://code.google.com/p/google-code-prettify/). This is a client-side syntax highlighter that I used on a private project I wrote and it was great. Just something to think about.
>
> Those are the only things I wanted to address.
>
> Take care,
>
> Jeremy Whitlock <jc...@gmail.com>
> Twitter: jcscoobyrs
>
>
>
>
Re: Bloodhound UI basics
Posted by Mat Booth <ma...@wandisco.com>.
On 1 February 2012 15:54, Jeremy Whitlock <jc...@gmail.com> wrote:
> Hello all,
> There were too many thread to respond to inline so I'll just address things here.
>
> 1) Bootstrap is just a CSS framework with a few very lightweight JavaScript plugins built on top of jQuery. It is not a templating engine nor is it going to have any impact on what we use on the backend to generate the markup sent to the client. That being said, we could easily update the current Trac templates to generate markup that is suitable for Bootstrap and move on. I have a good bit of familiarity with Bootstrap so once we start working on this, I'd love to help.
>
> 2) Geshi filter's performance is a concern that we should address sooner rather than later. Based on my understanding of how it's used, we could remove the dependency on it by having a real UI framework like bootstrap in place. Since all of the UI stuff is handled by Bootstrap, the backend templating system would not have to do as much as it does now which might make its importance diminish. I know that trying to get something out quick likely will not leave much room for a templating system overhaul now but I think the problem Geshi is solving on the backend could be alleviated by using a good framework on the frontend.
>
> 3) I know Geshi does more for Trac than just help render it's frontend, it also helps do syntax highlighting of the sources being displayed in the repository browser and such. I'm not an immediate +1 on removing it but again, I have a suggestion for a client-side solution that will help make our backend much leaner and performant: Google Code Prettify (http://code.google.com/p/google-code-prettify/). This is a client-side syntax highlighter that I used on a private project I wrote and it was great. Just something to think about.
>
> Those are the only things I wanted to address.
>
> Take care,
>
> Jeremy Whitlock <jc...@gmail.com>
> Twitter: jcscoobyrs
>
Thanks for the clear reply, Jeremy.
--
Regards,
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: Bloodhound UI basics
Posted by Jeremy Whitlock <jc...@gmail.com>.
Hello all,
There were too many thread to respond to inline so I'll just address things here.
1) Bootstrap is just a CSS framework with a few very lightweight JavaScript plugins built on top of jQuery. It is not a templating engine nor is it going to have any impact on what we use on the backend to generate the markup sent to the client. That being said, we could easily update the current Trac templates to generate markup that is suitable for Bootstrap and move on. I have a good bit of familiarity with Bootstrap so once we start working on this, I'd love to help.
2) Geshi filter's performance is a concern that we should address sooner rather than later. Based on my understanding of how it's used, we could remove the dependency on it by having a real UI framework like bootstrap in place. Since all of the UI stuff is handled by Bootstrap, the backend templating system would not have to do as much as it does now which might make its importance diminish. I know that trying to get something out quick likely will not leave much room for a templating system overhaul now but I think the problem Geshi is solving on the backend could be alleviated by using a good framework on the frontend.
3) I know Geshi does more for Trac than just help render it's frontend, it also helps do syntax highlighting of the sources being displayed in the repository browser and such. I'm not an immediate +1 on removing it but again, I have a suggestion for a client-side solution that will help make our backend much leaner and performant: Google Code Prettify (http://code.google.com/p/google-code-prettify/). This is a client-side syntax highlighter that I used on a private project I wrote and it was great. Just something to think about.
Those are the only things I wanted to address.
Take care,
Jeremy Whitlock <jc...@gmail.com>
Twitter: jcscoobyrs
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Feb 1, 2012 at 9:53 AM, Gary <ga...@wandisco.com> wrote:
> On 02/01/2012 02:10 PM, Mat Booth wrote:
>> On 1 February 2012 13:29, Olemis Lang<ol...@gmail.com> wrote:
>>> On Wed, Feb 1, 2012 at 7:11 AM, Mat Booth<ma...@wandisco.com> wrote:
>>>>
>>>> As y'all may know, the user interface in Trac at the moment is built
>>>> using Genshi template. Would using bootstrap involve ripping out that
>>>> dependency?
>>>>
>>>> I would be for this if it meant increased speed rendering the UI. As
>>>> awesome as Genshi is, its design does not lend itself to super-fast
>>>> template processing. [1]
>>>>
>>>> [1] http://genshi.edgewall.org/wiki/GenshiPerformance
>>>>
>>> -1 for removing Genshi . Trac is tightly coupled to that templates
>>> system . There was a discussion about this subject in ( trac-dev |
>>> trac-users ) MLs months ago and I go -1 for that . Maybe at a later
>>> phase ... and honestly I don't recommend doing so (but final decision
>>> involves much more reasoning by many people paying attention to some
>>> other details ;) .
>>>
>>> ... just my $0.02
>>> ;)
>>
>> So it's not a replacement UI template engine then? Just trying to
>> understand how Bootstap fits in.
>>
>
> Well, it looks to me like it is not about templating so much as css and
> javascript. If so, there is nothing to stop us as long as we don't remove
> aspects of the html that plugins currently depend on. If by using bootstrap
> we are able to lower the barrier to plugin creation, it seems worthwhile.
>
> If I have made any sense there then I think this is definitely worth looking
> into further.
>
I'll take a look at this later ... if it's just about javascript + css
, well , that should be ok .
;)
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet 12:35 Jan-20
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Gary <ga...@wandisco.com>.
On 02/01/2012 02:10 PM, Mat Booth wrote:
> On 1 February 2012 13:29, Olemis Lang<ol...@gmail.com> wrote:
>> On Wed, Feb 1, 2012 at 7:11 AM, Mat Booth<ma...@wandisco.com> wrote:
>>> As y'all may know, the user interface in Trac at the moment is built
>>> using Genshi template. Would using bootstrap involve ripping out that
>>> dependency?
>>>
>>> I would be for this if it meant increased speed rendering the UI. As
>>> awesome as Genshi is, its design does not lend itself to super-fast
>>> template processing. [1]
>>>
>>> [1] http://genshi.edgewall.org/wiki/GenshiPerformance
>>>
>> -1 for removing Genshi . Trac is tightly coupled to that templates
>> system . There was a discussion about this subject in ( trac-dev |
>> trac-users ) MLs months ago and I go -1 for that . Maybe at a later
>> phase ... and honestly I don't recommend doing so (but final decision
>> involves much more reasoning by many people paying attention to some
>> other details ;) .
>>
>> ... just my $0.02
>> ;)
>>
>
> So it's not a replacement UI template engine then? Just trying to
> understand how Bootstap fits in.
>
>
Well, it looks to me like it is not about templating so much as css and
javascript. If so, there is nothing to stop us as long as we don't
remove aspects of the html that plugins currently depend on. If by using
bootstrap we are able to lower the barrier to plugin creation, it seems
worthwhile.
If I have made any sense there then I think this is definitely worth
looking into further.
Cheers,
Gary
Re: Bloodhound UI basics
Posted by Mat Booth <ma...@wandisco.com>.
On 1 February 2012 13:29, Olemis Lang <ol...@gmail.com> wrote:
> On Wed, Feb 1, 2012 at 7:11 AM, Mat Booth <ma...@wandisco.com> wrote:
>> As y'all may know, the user interface in Trac at the moment is built
>> using Genshi template. Would using bootstrap involve ripping out that
>> dependency?
>>
>> I would be for this if it meant increased speed rendering the UI. As
>> awesome as Genshi is, its design does not lend itself to super-fast
>> template processing. [1]
>>
>> [1] http://genshi.edgewall.org/wiki/GenshiPerformance
>>
>
> -1 for removing Genshi . Trac is tightly coupled to that templates
> system . There was a discussion about this subject in ( trac-dev |
> trac-users ) MLs months ago and I go -1 for that . Maybe at a later
> phase ... and honestly I don't recommend doing so (but final decision
> involves much more reasoning by many people paying attention to some
> other details ;) .
>
> ... just my $0.02
> ;)
>
So it's not a replacement UI template engine then? Just trying to
understand how Bootstap fits in.
--
Regards,
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Feb 1, 2012 at 7:11 AM, Mat Booth <ma...@wandisco.com> wrote:
> As y'all may know, the user interface in Trac at the moment is built
> using Genshi template. Would using bootstrap involve ripping out that
> dependency?
>
> I would be for this if it meant increased speed rendering the UI. As
> awesome as Genshi is, its design does not lend itself to super-fast
> template processing. [1]
>
> [1] http://genshi.edgewall.org/wiki/GenshiPerformance
>
-1 for removing Genshi . Trac is tightly coupled to that templates
system . There was a discussion about this subject in ( trac-dev |
trac-users ) MLs months ago and I go -1 for that . Maybe at a later
phase ... and honestly I don't recommend doing so (but final decision
involves much more reasoning by many people paying attention to some
other details ;) .
... just my $0.02
;)
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Mat Booth <ma...@wandisco.com>.
As y'all may know, the user interface in Trac at the moment is built
using Genshi template. Would using bootstrap involve ripping out that
dependency?
I would be for this if it meant increased speed rendering the UI. As
awesome as Genshi is, its design does not lend itself to super-fast
template processing. [1]
[1] http://genshi.edgewall.org/wiki/GenshiPerformance
--
Regards,
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: Bloodhound UI basics
Posted by Joachim Dreimann <jo...@wandisco.com>.
+1 for Bootstrap (third) from iteration 1. Also Bootstrap v2 will be
released soon (was due yesterday) with better mobile / tablet support
etc.
On 31 January 2012 22:23, Olemis Lang <ol...@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 12:07 PM, Joachim Dreimann
> <jo...@wandisco.com> wrote:
>
> [...]
>
> cool !
> Below I mention a few ideas , mainly focused on how to get this
> implemented in the theme itself
> ;)
That's great actually, I think we should go straight from these rough
drafts to implementation. I'm more happy to refine the design in html
than to come up with things that may be easy to mock up but difficult
to implement.
>
> This means that parts of this message are not just about the design ,
> but also about the underlying machinery to make the theme magic happen
> :-/
>
> [...]
>
>> 2. Content should be shown in a pane larger than half the screen width
>> on the left.
>
> good to know . I was thinking of using a 50% - 50% layout initially
> :$
> 66% - 33% should be ok ? or maybe some combination of fixed & relative
> width (i.e. using height & max-height) will be better ?
Yes, 66% + 33% width will be fine to start with. My thinking here is
that content should always be your focus, Activity is just a view of
what happened to the content recently.
Once we have something up and running we can have a play around with
different fixed/relative widths for either half, I'll happily get
involved with that.
>> 3. Activity relating to the content is shown on the remaining width on the right
>> (this is essentially Trac's timeline feature with context-specific
>> filters applied).
>
> once I reviewed previous mockup I was thinking of considering activity
> to be yet another widget in the dashboard ... afaics the idea now is a
> bit different than that ... isn't it ?
Yes, I actually found the Activity view useful in all parts of the
ticket system. For example the Component view:
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_componentView.png
( Mockup http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_componentView.bmml
)
This is consistent across the dashboard, project, version, milestone,
component and ticket views.
In some future version this would also be the natural place to show
activity graphs (see .png above), but that's not needed for our
initial work.
> [...]
>> The basic page setup would stay consistent throughout all of the
>> Ticket system in Bloodhound.
>
> ... so my aforementioned impression of including the timeline as part
> of the dashboard is not valid anymore , isn't it ?
As above, this applies everywhere in the ticket system. The Dashboard
is only special in that it pulls in data relevant to the user from
everywhere - all other screens just provide a narrower focus.
>
> if that's the case , options to get this done are as follows :
>
> 1- implement component outside core (e.g. side-by-side with
> plugins migrated from Trac-Hacks ;) that detects that both
> ticket and timeline systems are enabled and , if this is
> the case , inserts the timeline (i.e. using ITemplateFilter ... afaicr )
> 2- implement such behavior and package that component in
> the theme itself
> 3- modify genshi templates in core components to include timeline
> and/or implement that idea in core distribution
> (maybe in TicketModule itself, but maybe others ...)
>
> ... beware of the fact that timeline and ticket modules are separate
> entities in Trac .
>
> why do I mention options above ? So as to know if the theme should
> be changed or something else needs to be implemented
>
> [...]
>>
>> Mockup files here (these will be updated regularly:
>> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.bmml
>> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/assets/bloodhound_logo.png
>
> ... about logo file ; it'd be nice to have a similar picture in
> transparent background ...
I'd go one further and say that we need a vector graphic of the logo,
at least of the hound. I've never met the person that created the
logo, does anyone else know whether we can still get this? If not we
may go down the road of tracing it..
- Joe
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Fri, Feb 3, 2012 at 8:11 AM, Joachim Dreimann
<jo...@wandisco.com> wrote:
>
> > [...]
> > ... so please let's focus on these screenshots [4]_ [5]_ so as to
> > compare them with the idea sketched in previous wireframe (link above
> > ;) . afaics changes needed (top-down taking wireframe as a reference
> > ;) are the following :
> >
> > 1- Remove project name + description ? Or that part was just skipped ?
>
> I'm not sure where this was shown previously?
oh ! sorry . I apologize . I thought I had mentioned this before in
this thread [1]_ but maybe I forgot .
Fact is that in Trac=0.11 default template includes project name +
description in header .
I paid attention to 0.13 and it seems those fields are not in there
anymore (I could only see them in title and open search link
definition) .
:-/
So I was asking if those fields should be visible like in 0.11 (and
screenshots ;) or hidden like in 0.13 just to confirm what should be
done ;)
It's possible to include show / hide option as well ... so ,
everything is possible .
> Maybe the idea is a bit more clear when it includes what it would look
> like once in full flow, with multiple projects set up, etc:
> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboard.png
>
> I haven't sent this before as I'm not sure yet if the lift of projects
> should be above or below the list of tickets for example..
IMO , in the not-so-immediate term (and multi-project support is also
not-so-immediate feature) dashboard should be configurable by the user
. I think of it looking like Blogger layout editor or iGoogle . Users
have a bunch of widgets to choose from , select some , arrange them
the way they want ... save , and that should be displayed every time
he/she accesses the site . So IMO there should be both an admin panel
(site-specific default dashboard) for this and a preferences panel (so
that each user may be able to change it if they want ... ok , ok ,
permissions matter ;) .
... maybe I'm thinking way long into the future ...
> But I may
> as well post it for discussion. I would personally say that testing
> the alternatives is the only way to get a good answer to this.
>
;)
>
> > 2- Keep only login / logout items in metanav + a drop down menu
> > displaying the rest (i.e. Settings) .
> > I think It's necessary to mention up to this point
> > that (IMO) metanav != settings . AFAICS preferences (one item in
> > metanav ;) ≃ settings ;) ; hence clarification needed
> > btw metanav in screenshots was based on GMail look and feel .
> > * Is it ok ?
> > * Should I keep it high like in screenshots or closer to
> > the metanav ?
>
> What's called settings in the mockup can be changed to preferences,
> that's not a problem.
ok . In Trac the specific label to navigate to preferences section is
defined by `trac.prefs.web_ui.PreferencesModule` . This module may be
enabled or not , so the link should be visible by default , but maybe
not . So, as far as the theme is concerned , it should only filter
what metanav links will be displayed . I've done something like that
before for TracMacTheme [3]_ . In there [4]_ it's possible to have
only login / logout links (this also include other third-party metanav
items like `Open ID login` ) + `preferences` . All other metanavs may
be included in a separate drop-down menu to control horizontal
overflow , but there's an option in trac.ini so as to control which
ones are visible and which ones will be included in the drop down menu
.
this is mostly jftr
;)
> In terms of that being a dropdown, GMail actually only gives you
> display density settings to choose, then just links to the actual
> settings page.
>
> I think we'll be fine making settings/preferences link
> straight to the appropriate page for now.
>
ok . But considering the fact that Trac behaves different than GMail
... in the sense that metanav contributors in plugins may add further
links (e.g. RPC API -lists RPC features supported by the environment-
, Developer tools -quick access to Trac developer tools for debug- ,
... ) I wonder where they will be included in the user interface ,
... or maybe they won't be included at all. As you can see I'm
thinking about how to cope with the flexibility provided by Trac at
present, not just focusing on the «default» appearance of the site
(which is what you sketched in wireframes and I'll stick to that ;) .
Or maybe the decision is to remove those extension points .
>
> > 3- Move search + quick create ticket button to the left
>
> Yes :) This is mainly because they are the main navigational elements
> and most content that people frequently interact with will also be
> close to the top / left area, that minimises the distance you'd have
> to travel from navigation to content.
>
+1
:)
>
> > 4- Suggestion : In search box add a drop down menu looking
> > like an icon so that users will be able to select the filter(s)
> > they'll use to search for the information they want
> > (i.e. make that magic happen when clicking on search
> > icon inside search box)
>
> The way GMail makes filters accessible from within the search box is
> very good.
hmmm ... that's a good one ...
;)
I was thinking of something like what's shown in this image [5]_ .
Google search box in top-right corner should also provides a drop down
menu to select Wikipedia , Bing , ... In this case drop down menu
should contain search filters (e.g. Changesets , Milestones , Tickets
, Wiki, ...) . Search button just like in your wireframes .
>
> I do think the Search button to the right of the box is
> needed as well
+1
[...]
>
> > 5- Use tabs for mainnav rather than the menu ?
> > If this is the case how submenus (customizable using
> > plugins) will look like ?
>
> Submenus would queue items to the right of where it says Reports in
> the top right corner, up until 3/4 plugins are shown, then provide a
> "More" dropdown with the rest. I'm happy to provide a mockup for this
> later / Monday if that sentence doesn't make sense :)
>
when I mentioned sub menus I was thinking of something like this [5]_
. I'm not sure about whether we are talking about the same thing ...
>
>
> > 6- Add a tabs carousel (just like shown in screenshots). This
> > one should be a MUST due to the fact that overflow in
> > metanav MUST be controlled . This might happen due to :
> > * small screen dimensions
> > * small windows size (maybe even if it's resized after
> > web page is rendered)
>
> By carousel, do you mean what's displayed with the buttons where the
> mouse hovers in this image?
> https://plus.google.com/photos/118444449354330048631/albums/5704585989523271585/5704588538735269650
>
I've done this before so ... better see it in action [2]_ ;)
>
> In that case I have to say I'm strongly against the carousel. As a
> method of dealing with 'overspill', ie too many items, this can work
> in media / product libraries where you essentially discover options,
> often serendipitously. Here it could lead to major navigational items
> to not be visible, because they were first in the list and the user
> has scrolled too far right. When that happens the next step would
> always be frustration.
>
> A dropdown called 'More' if plugins where already listed next to the
> navigation once a certain number of items is reached, or better a
> Plugin dropdown that contains all of them, is a better solution from a
> usability perspective.
>
that's similar to what I'd mentioned for TracMacTheme [4]_ .
I think I agree with you .
In there there's a «Start» button (like in many OS such as Mac OS X ;)
that displays a drop down menu containing mainnav items .
>
> > 7- Add breadcumbs nav in top-left corner
>
> Yes, within the tabbed area, because this isn't shared between the
> tabbed things, and can stay persistent within each tab.
>
;)
>
> > 8- Insert ctxtnav menu in top-right corner (instead of previous tabs)
>
> I'm not sure what you mean by this.. context nav, as in Ticket/Wiki/Source?
>
Context navigation items in this page [6]_ are `Start Page` , `Index`
, `History`
;)
In your wireframe it is a bit confusing to me whether they are `Custom
Query` , `Reports` (to the right under tabs) or `My Tickets` , `Custom
Query` , `Reports` close to Dashboard label / title
>
> > 9- Activity column won't be part of the theme ... unless stated otherwise
>
> I understood your first reply to this thread as saying that it would
> have to be part of the theme?
>
... well , my reply was a bit dense I guess ... even for myself now
that I read it once again
:-/
summarizing my conclusion is that there are 3 or 4 ways to get this
done , and I have no strong arguments (so far) to decide which one
will be the right one . So IMO we still need to polish the diamond so
as to make it shine ;)
> > 10- Modify footer
>
> I haven't put much thought into the footer yet, its seems fine the way
> it is currently.
>
well ... I already changed the footer [7]_ :P
the text to the right may be configured in trac.ini , text to the left is fixed
;)
> > 11- Add support to customize theme colors . This is a built-in feature of
> > ThemeEnginePlugin btw , so ... no big deal .
>
> Not sure this is an important function. I would not implement this
> unless users ask for it. I think we should just go with the Bootstrap
> defaults for now. We don't have to use every feature that is available
> straightaway :)
>
ok , later we shall see ;)
>
> >
> > Please I'd appreciate if you could review the TODO list above and cmiiw
> >
> > [...]
> >
> > General considerations used to build the theme :
> >
> > 1- control scrolling using a div inside the web page
> > (<= therefore nav items are always at hand ;)
> > 2- make it work for 640 x 400 resolution [2]_ [3]_
> > (this one was taken before starting this thread ;)
>
> Which devices to you envisage with such a low resolution?
Hmmm ... I was thinking more about e.g. myself using my notebook and
arranging some windows using tile / cascade commands . They'll be
distributed side by side considering available space . IOW , I was
assuming that you might render the website inside a window (not full
screen) . I played with the GMail thingy (once again ;) and it seems
this is similar to what they do as well ;)
>
> I can only
> think of phones/tablets, where actual size is much more important than
> resolution - as an example when the resolution was doubled with retina
> displays in iphones, buttons stayed the same size because the critical
> thing here is actually the size of your finger, not the pixels.
>
yes , u r right . Sorry but I don't use these terms consistently . It
was hard for me to pass web design test in college ... ;)
> > PS: For further screenshots (at different points in development
> > process) the whole album [1]_ should be publicly available . I hope
> > you all can see it .
>
> Yes, I can see them..
:)
>
> We should try to get them into the Bloodhound
> SVN system as soon as possible though, rather them host them
> externally.
>
... something I cannot do ... at present ...
:'(
.. [1] Bloodhound Theme/Dashboard design
(http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201201.mbox/%3c4F15D1DE.7080009@wandisco.com%3e)
.. [2] 1499390 - Menu carousel
(http://www.youtube.com/playlist?list=PL42CCE0831D836673&feature=plcp)
.. [3] MacTheme @ trac-hacks
(http://trac-hacks.org/wiki/MacTheme)
.. [4] Mac OS theme - screenshot
(http://bitbucket.org/olemis/trac-macos/raw/tip/tracmacos/htdocs/screenshot.png)
.. [5] Hierarchical navigation menus
(http://trac-hacks.org/attachment/wiki/MenusPlugin/menusplugin.png)
.. [6] Welcome to Apache Bloodhound (incubating)
(https://issues.apache.org/bloodhound)
.. [7] New footer ...
(https://lh5.googleusercontent.com/-Z7u67GIJ5x4/TyscjOsN8DI/AAAAAAAAAZ4/3v7_52KdooQ/w343-h155-n-k/BH_theme_13.png)
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ...
@elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb
Follow @olemislc Reply Retweet 12:59 Feb-01
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Joachim Dreimann <jo...@wandisco.com>.
> [...]
> ... so please let's focus on these screenshots [4]_ [5]_ so as to
> compare them with the idea sketched in previous wireframe (link above
> ;) . afaics changes needed (top-down taking wireframe as a reference
> ;) are the following :
>
> 1- Remove project name + description ? Or that part was just skipped ?
I'm not sure where this was shown previously?
Maybe the idea is a bit more clear when it includes what it would look
like once in full flow, with multiple projects set up, etc:
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboard.png
I haven't sent this before as I'm not sure yet if the lift of projects
should be above or below the list of tickets for example.. But I may
as well post it for discussion. I would personally say that testing
the alternatives is the only way to get a good answer to this.
> 2- Keep only login / logout items in metanav + a drop down menu
> displaying the rest (i.e. Settings) .
> I think It's necessary to mention up to this point
> that (IMO) metanav != settings . AFAICS preferences (one item in
> metanav ;) ≃ settings ;) ; hence clarification needed
> btw metanav in screenshots was based on GMail look and feel .
> * Is it ok ?
> * Should I keep it high like in screenshots or closer to
> the metanav ?
What's called settings in the mockup can be changed to preferences,
that's not a problem.
In terms of that being a dropdown, GMail actually only gives you
display density settings to choose, then just links to the actual
settings page. I think we'll be fine making settings/preferences link
straight to the appropriate page for now.
> 3- Move search + quick create ticket button to the left
Yes :) This is mainly because they are the main navigational elements
and most content that people frequently interact with will also be
close to the top / left area, that minimises the distance you'd have
to travel from navigation to content.
> 4- Suggestion : In search box add a drop down menu looking
> like an icon so that users will be able to select the filter(s)
> they'll use to search for the information they want
> (i.e. make that magic happen when clicking on search
> icon inside search box)
The way GMail makes filters accessible from within the search box is
very good. I do think the Search button to the right of the box is
needed as well though (GMail chooses a magnifying glass for that).
People scan pages for the word Search and omitting it would make it
less obvious where to search.
> 5- Use tabs for mainnav rather than the menu ?
> If this is the case how submenus (customizable using
> plugins) will look like ?
Submenus would queue items to the right of where it says Reports in
the top right corner, up until 3/4 plugins are shown, then provide a
"More" dropdown with the rest. I'm happy to provide a mockup for this
later / Monday if that sentence doesn't make sense :)
> 6- Add a tabs carousel (just like shown in screenshots). This
> one should be a MUST due to the fact that overflow in
> metanav MUST be controlled . This might happen due to :
> * small screen dimensions
> * small windows size (maybe even if it's resized after
> web page is rendered)
By carousel, do you mean what's displayed with the buttons where the
mouse hovers in this image?
https://plus.google.com/photos/118444449354330048631/albums/5704585989523271585/5704588538735269650
In that case I have to say I'm strongly against the carousel. As a
method of dealing with 'overspill', ie too many items, this can work
in media / product libraries where you essentially discover options,
often serendipitously. Here it could lead to major navigational items
to not be visible, because they were first in the list and the user
has scrolled too far right. When that happens the next step would
always be frustration.
A dropdown called 'More' if plugins where already listed next to the
navigation once a certain number of items is reached, or better a
Plugin dropdown that contains all of them, is a better solution from a
usability perspective.
> 7- Add breadcumbs nav in top-left corner
Yes, within the tabbed area, because this isn't shared between the
tabbed things, and can stay persistent within each tab.
> 8- Insert ctxtnav menu in top-right corner (instead of previous tabs)
I'm not sure what you mean by this.. context nav, as in Ticket/Wiki/Source?
> 9- Activity column won't be part of the theme ... unless stated otherwise
I understood your first reply to this thread as saying that it would
have to be part of the theme?
> 10- Modify footer
I haven't put much thought into the footer yet, its seems fine the way
it is currently.
> 11- Add support to customize theme colors . This is a built-in feature of
> ThemeEnginePlugin btw , so ... no big deal .
Not sure this is an important function. I would not implement this
unless users ask for it. I think we should just go with the Bootstrap
defaults for now. We don't have to use every feature that is available
straightaway :)
>
> Please I'd appreciate if you could review the TODO list above and cmiiw
>
> [...]
>
> General considerations used to build the theme :
>
> 1- control scrolling using a div inside the web page
> (<= therefore nav items are always at hand ;)
> 2- make it work for 640 x 400 resolution [2]_ [3]_
> (this one was taken before starting this thread ;)
Which devices to you envisage with such a low resolution? I can only
think of phones/tablets, where actual size is much more important than
resolution - as an example when the resolution was doubled with retina
displays in iphones, buttons stayed the same size because the critical
thing here is actually the size of your finger, not the pixels.
> 3- use jQuery-UI CSS [6]_ as much as possible
> 4- maybe some others ... I'll mention once I recall ... ;)
>
> PS: For further screenshots (at different points in development
> process) the whole album [1]_ should be publicly available . I hope
> you all can see it .
Yes, I can see them.. We should try to get them into the Bloodhound
SVN system as soon as possible though, rather them host them
externally.
- Joe
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 31, 2012 at 5:23 PM, Olemis Lang <ol...@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 12:07 PM, Joachim Dreimann <jo...@wandisco.com> wrote:
I'm going to start with this . Hopefully I'll finish everything today
, part of this will be ready for sure ;)
Nonetheless , before doing so I wanted to know exactly what should be
changed in the current implementation .
[...]
>
>
> > That may look something like this:
> > http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.png
> >
>
> /me looking at this btw
>
... so please let's focus on these screenshots [4]_ [5]_ so as to
compare them with the idea sketched in previous wireframe (link above
;) . afaics changes needed (top-down taking wireframe as a reference
;) are the following :
1- Remove project name + description ? Or that part was just skipped ?
2- Keep only login / logout items in metanav + a drop down menu
displaying the rest (i.e. Settings) .
I think It's necessary to mention up to this point
that (IMO) metanav != settings . AFAICS preferences (one item in
metanav ;) ≃ settings ;) ; hence clarification needed
btw metanav in screenshots was based on GMail look and feel .
* Is it ok ?
* Should I keep it high like in screenshots or closer to
the metanav ?
3- Move search + quick create ticket button to the left
4- Suggestion : In search box add a drop down menu looking
like an icon so that users will be able to select the filter(s)
they'll use to search for the information they want
(i.e. make that magic happen when clicking on search
icon inside search box)
5- Use tabs for mainnav rather than the menu ?
If this is the case how submenus (customizable using
plugins) will look like ?
6- Add a tabs carousel (just like shown in screenshots). This
one should be a MUST due to the fact that overflow in
metanav MUST be controlled . This might happen due to :
* small screen dimensions
* small windows size (maybe even if it's resized after
web page is rendered)
7- Add breadcumbs nav in top-left corner
8- Insert ctxtnav menu in top-right corner (instead of previous tabs)
9- Activity column won't be part of the theme ... unless stated otherwise
10- Modify footer
11- Add support to customize theme colors . This is a built-in feature of
ThemeEnginePlugin btw , so ... no big deal .
Please I'd appreciate if you could review the TODO list above and cmiiw
[...]
General considerations used to build the theme :
1- control scrolling using a div inside the web page
(<= therefore nav items are always at hand ;)
2- make it work for 640 x 400 resolution [2]_ [3]_
(this one was taken before starting this thread ;)
3- use jQuery-UI CSS [6]_ as much as possible
4- maybe some others ... I'll mention once I recall ... ;)
PS: For further screenshots (at different points in development
process) the whole album [1]_ should be publicly available . I hope
you all can see it .
.. [1] Bloodhound theme under the hood
(https://plus.google.com/photos/118444449354330048631/albums/5704585989523271585)
.. [2] Screenshot # 9
(https://lh6.googleusercontent.com/-tiG7eAqt-rI/TyrE15mUzLI/AAAAAAAAAYg/MhDzVgWrxRw/w191-h139-n-k/BH_theme_9.png)
.. [3] Screenshot #11
(https://lh6.googleusercontent.com/-UtQCHGUTI5Y/TyrEnrUxOII/AAAAAAAAAYQ/A7OBICTne1M/w330-h209-k/BH_theme_11.png)
.. [4] Screenshot #7
(https://lh4.googleusercontent.com/-IwVo0xRPJ6Y/TyrFDUEUlxI/AAAAAAAAAYw/PneIvGVgNkc/w295-h201-n-k/BH_theme_7.png)
.. [5] Screenshot #12
(https://lh6.googleusercontent.com/-vrHzSITWnSk/TyrCu4hg1-I/AAAAAAAAAYE/DtdQsYsoZmg/w547-h346-k/BH_theme_12.png)
.. [6] Bloodhound jQuery UI custom theme
(http://goo.gl/pbHhV)
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ...
@elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb
Follow @olemislc Reply Retweet 12:59 Feb-01
Get this email app!
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 31, 2012 at 12:07 PM, Joachim Dreimann
<jo...@wandisco.com> wrote:
> Hello all,
>
:)
> I've spent about two weeks coming up with a general idea of how to
> improve the UI for the first release of Bloodhound.
>
cool !
Below I mention a few ideas , mainly focused on how to get this
implemented in the theme itself
;)
This means that parts of this message are not just about the design ,
but also about the underlying machinery to make the theme magic happen
:-/
[...]
>
> My thoughts so far are:
>
> 1. Search should play a major role in navigation.
+1
> 2. Content should be shown in a pane larger than half the screen width
> on the left.
good to know . I was thinking of using a 50% - 50% layout initially
:$
66% - 33% should be ok ? or maybe some combination of fixed & relative
width (i.e. using height & max-height) will be better ?
> 3. Activity relating to the content is shown on the remaining width on the right
> (this is essentially Trac's timeline feature with context-specific
> filters applied).
once I reviewed previous mockup I was thinking of considering activity
to be yet another widget in the dashboard ... afaics the idea now is a
bit different than that ... isn't it ?
> 4. The minimum width we should design for is 1024px,
> because that covers every device down to small tablets in
> landscape mode (including the 7" Kindle Fire).
ok , understood ;)
> 5. It should be possible to create tickets everywhere without leaving
> the current page.
>
+1
> That may look something like this:
> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.png
>
/me looking at this btw
[...]
>
> The basic page setup would stay consistent throughout all of the
> Ticket system in Bloodhound.
... so my aforementioned impression of including the timeline as part
of the dashboard is not valid anymore , isn't it ?
if that's the case , options to get this done are as follows :
1- implement component outside core (e.g. side-by-side with
plugins migrated from Trac-Hacks ;) that detects that both
ticket and timeline systems are enabled and , if this is
the case , inserts the timeline (i.e. using ITemplateFilter ... afaicr )
2- implement such behavior and package that component in
the theme itself
3- modify genshi templates in core components to include timeline
and/or implement that idea in core distribution
(maybe in TicketModule itself, but maybe others ...)
... beware of the fact that timeline and ticket modules are separate
entities in Trac .
why do I mention options above ? So as to know if the theme should
be changed or something else needs to be implemented
[...]
>
> Mockup files here (these will be updated regularly:
> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboardNew.bmml
> http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/assets/bloodhound_logo.png
... about logo file ; it'd be nice to have a similar picture in
transparent background ...
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Get a signature like this. CLICK HERE.
Re: Bloodhound UI basics
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jan 31, 2012 at 15:13, Jeremy Whitlock <jc...@gmail.com> wrote:
> On Jan 31, 2012, at 10:07 AM, Joachim Dreimann wrote:
>
>> Hello all,
>>
>> I've spent about two weeks coming up with a general idea of how to
>> improve the UI for the first release of Bloodhound.
>
>
> I'm just getting involved here and I do a lot of web development so I figured I'd point you at Bootstrap, from Twitter:
>
> http://twitter.github.com/bootstrap/
I would very much second this suggestion. I've also used Bootstrap for
my own work (though not with the added complexity of Less). It is
designed around a 940px screen (close to the 1024 that Joe was
suggesting). Bootstrap likely provides all of the UI elements needed
by Apache Bloodhound, and it looks really good :-)
>...
Cheers,
-g
Re: Bloodhound UI basics
Posted by Jeremy Whitlock <jc...@gmail.com>.
On Jan 31, 2012, at 10:07 AM, Joachim Dreimann wrote:
> Hello all,
>
> I've spent about two weeks coming up with a general idea of how to
> improve the UI for the first release of Bloodhound.
I'm just getting involved here and I do a lot of web development so I figured I'd point you at Bootstrap, from Twitter:
http://twitter.github.com/bootstrap/
I've been using it a lot recently and here are two examples:
http://jcscoobyrs.github.com/directv-remote-api/
http://jcscoobyrs.github.com/
The reason I bring this up is if we can avoid reinventing the wheel to get a useful app out now and then tailor things to suite feedback/preference, it might save us some time without compromising on look by using Twitter's Bootstrap. One of the best things about using Bootstrap is that it can be customized really easy using Less (http://lesscss.org/). Another cool thing is that it uses CSS classes for just about everything so you could easily migrate away from Bootstrap without changing your markup at all if you felt so inclined.
After writing a few web-based UIs, I have come to love the idea of letting someone else spending the time/effort to create a great starting point. ;)
Take care,
Jeremy Whitlock <jc...@gmail.com>
Twitter: jcscoobyrs