Tips on working with designers

[Nolan Darilek]

I'm working on my first serious Lift app that will be deployed to
production. As such, it's my first time working with a designer.

How do folks normally do this? I can hand my designer a copy of the
webapp/templates-hidden/default.html file and associated
stylesheets/javascript, but I'm wondering if that is the best approach?
My concern is that he'd then need the full app running on his system to
see any changes, which seems prohibitive.

Another idea would be letting him start from scratch, then inserting the
various data-lift attributes where appropriate.

My other concern is with wizard-all.html. The version on the wiki is a
partial fragment and uses namespaced attributes. This doesn't seem
particularly designer-friendly. Is there a more designer-friendly way to
define wizard-all.html? I've gone through and used data-lift where
appropriate, but this can't be done everywhere.

Thanks.

[Diego Medina]

Hi,

First, congrats on your serious Lift project!

See comments below:

On Tue, Jan 24, 2012 at 12:36 PM, Nolan Darilek <no...@thewordnerd.info> wrote:
> I'm working on my first serious Lift app that will be deployed to
> production. As such, it's my first time working with a designer.
>
> How do folks normally do this? I can hand my designer a copy of the
> webapp/templates-hidden/default.html file and associated

There is an example on the simply lift book of a chat app, and as a
side effect it shows how to deal with a designer:

http://stable.simply.liftweb.net/#toc-Chapter-2
the html is this:

https://gist.github.com/1671418

On that page you see the index.html, notice how it included the
"header/surrounding " html, this allows your designer to open the page
in Firefox (straight from File -> Open) and he/she will see how the
page would look even running inside lift.

Notice how there are a few lines with the class "clearable" . All you
need to do on your render method in Lift is add :

def render = "li *" #> msgs & ClearClearable

(the ClearClreable is the key here). It basically tells Lift to delete
those lines while processing the page. So, your designer can see how a
list would look, and on your real app, running in jetty/tomcat/etc
will show you the "real" data.

The one drawback is keeping the "header section" in sync across all
your pages and the one real default.html.

Hope this gives you some direction.

Disclaimer, I haven't actually worked with a designer, but this is how
I work with myself, while working on the html, I just open the page in
Chrome, so I can make changes and I don't have to wait for jetty to
reload the page.

Regards,

Diego

> stylesheets/javascript, but I'm wondering if that is the best approach? My
> concern is that he'd then need the full app running on his system to see any
> changes, which seems prohibitive.
>
> Another idea would be letting him start from scratch, then inserting the
> various data-lift attributes where appropriate.
>
> My other concern is with wizard-all.html. The version on the wiki is a
> partial fragment and uses namespaced attributes. This doesn't seem
> particularly designer-friendly. Is there a more designer-friendly way to
> define wizard-all.html? I've gone through and used data-lift where
> appropriate, but this can't be done everywhere.
>
> Thanks.
>

> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[David Pollak]

This is the goal of designer-friendly templates... the ability to open any template in a browser and have it drawn correctly for the designer and have it validate correctly.

As you point out, wizard-all is an exception to the designer friendly rule and at some point that exception needs to go away.

As you go through your process with your designer, I'd love to see progress blog posts or postings to this group.  Being able to improve Lift's designer friendliness through the 2.5 cycle would be excellent.

Thanks,

David

PS -- I only had half a Lift day yesterday because I had to spend time with a plumbing inspector (that's code for "even though I hired a general contractor, there's no construction project where you're not a GC yourself.") so I'm making sure the Lift community gets my time today.

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Nolan Darilek]

Cool, thanks to both of you.

I'm not sure how skilled this designer is. We're both volunteers working on this project (I'll definitely write about it once it launches). So it will be interesting to see how difficult it is to mesh the coded back-end with whatever design he comes up with.

At this point I think I'm going to have him start from scratch, tell him to stick with HTML 5 and communicate which page elements Lift needs to populate (I.e. menu, main body, etc.) Clearable will help in that he can populate the template with sample data, then Lift can clear it out when it renders. Thanks for that.

I'll report back on how it goes. My only concern is wizard-all, but we'll see what happens.

[Jack Park]

Nolan,

I agree that this is an important aspect of using Lift that will
benefit greatly from "looking over your shoulder" as you evolve
collaborative practices.

Jack

[Lukasz Kuczera]

From my experiences your best bet is to avoid putting any styling info
in the Scala code. Sometimes it might look hard but its perfectly
doable.

On Jan 24, 7:20 pm, Nolan Darilek <no...@thewordnerd.info> wrote:
> Cool, thanks to both of you.
>
> I'm not sure how skilled this designer is. We're both volunteers working
> on this project (I'll definitely write about it once it launches). So it
> will be interesting to see how difficult it is to mesh the coded
> back-end with whatever design he comes up with.
>
> At this point I think I'm going to have him start from scratch, tell him
> to stick with HTML 5 and communicate which page elements Lift needs to
> populate (I.e. menu, main body, etc.) Clearable will help in that he can
> populate the template with sample data, then Lift can clear it out when
> it renders. Thanks for that.
>
> I'll report back on how it goes. My only concern is wizard-all, but
> we'll see what happens.
>
> On 01/24/2012 11:53 AM, David Pollak wrote:
>
>
>
>
>
>
>
>
>
> > On Tue, Jan 24, 2012 at 9:47 AM, Diego Medina <di...@fmpwizard.com
> > <mailto:di...@fmpwizard.com>> wrote:
>
> >     Hi,
>
> >     First, congrats on your serious Lift project!
>
> >     See comments below:
>
> >     On Tue, Jan 24, 2012 at 12:36 PM, Nolan Darilek

> >     di...@fmpwizard.com <mailto:di...@fmpwizard.com>

> >    http://www.fmpwizard.com
>
> >     --
> >     Lift, the simply functional web framework:http://liftweb.net
> >     Code:http://github.com/lift
> >     Discussion:http://groups.google.com/group/liftweb
> >     Stuck? Help us help you:
> >    https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
> > --

> > Visi.Pro, Cloud Computing for the Rest of Ushttp://visi.pro
> > Lift, the simply functional web frameworkhttp://liftweb.net

[madrenegade]

If you are using HTML5 than I would recommend to take advantage of the
data-lift attribute to invoke snippets. In my snippets I use css
selectors based on another attribute (data-name)
to do the binding. For example a part of my html code looks like this:
<article data-lift="BlogPost">
<header>
<h1 data-name="title">Here goes the Blog title</h1>
</header>
<p data-name="text">Here goes the blog text</p>
</article>

In my opinion this is the best way to be designer-friendly because it
keeps styling information and content separate (other than with using
style="lift:BlogPost").

>>> def render = "li *" #> msgs& ClearClearable

[David Pollak]

I just opened a ticket: http://www.assembla.com/spaces/liftweb/tickets/1185-support-data-name-attribute-in-css-selector-transforms

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

[David Whittaker]

+1, that's a really cool idea.  One little change I might make is to go with something less generic than data-name though.  The use of these data-* attributes seems to be picking up steam and I'd hate to see a collision with some UI feature.  Maybe data-lift-id?

[David Pollak]

On Wed, Jan 25, 2012 at 9:57 AM, David Whittaker <da...@iradix.com> wrote:

+1, that's a really cool idea.  One little change I might make is to go with something less generic than data-name though.  The use of these data-* attributes seems to be picking up steam and I'd hate to see a collision with some UI feature.  Maybe data-lift-id?

Welllll..... I was thinking about:

data-whatever and then data-id="whatever": 

   <div data-whatever>Put something in here</div>

-or-

  <div data-id="whatever">Put something in here</div>

so that you can match either with the attribute name or with a well-named attribute.  But that runs smack into the "there are too many ways to do stuff in Lift" criticism (see how a good idea can be a bad idea).  on the other hand, it reduces the number of characters in markup.

Thoughts?

[David Whittaker]

Hmm... so would the corresponding selectors look something like:

"$whatever *" #> bla bla bla

"$id=whatever *" #> bla bla bla

Replacing $ with whatever character seems most appropriate (but data = money - makes sense to me :)).  In other words, it's just a shorthand for matching arbitrary data attributes?

[David Pollak]

On Wed, Jan 25, 2012 at 10:30 AM, David Whittaker <da...@iradix.com> wrote:

Hmm... so would the corresponding selectors look something like:

"$whatever *" #> bla bla bla

"$id=whatever *" #> bla bla bla

Replacing $ with whatever character seems most appropriate (but data = money - makes sense to me :)).  In other words, it's just a shorthand for matching arbitrary data attributes?

Awesome.  I love it!

[Andrew Wong]

I like <div data-id="whatever">Put something in here</div>. 

I will be leaving my project by the end of the year and will have to train a new college grad to take over.  I know people think Scala is demanding and you shouldn't try to escape the learning curve, but I think for adoption purposes making things obvious is worth a few extra characters.  I have been learning and using Lift since August by myself and I have had constant double takes because of the "Wait, what exactly is implicit here?" design.

- Andrew

[madrenegade]

I would also prefer something like data-id="whatever" but maybe name it data-lift-id to avoid name clashes.
And then the css sel could be "$whatever". The $ seems nice (jquery also uses it for element selection)

[Andreas Joseph Krogh]

On 01/26/2012 07:41 AM, madrenegade wrote:

I would also prefer something like data-id="whatever" but maybe name it data-lift-id to avoid name clashes.
And then the css sel could be "$whatever". The $ seems nice (jquery also uses it for element selection)

+1 for the the "data-lift-xxx" namespace to avoid conflicts.

-- 
Andreas Joseph Krogh <and...@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

[Nolan Darilek]

OK, here are a couple challenges that came up. I don't necessarily have solutions for these, I'm just throwing them out.

Being blind, my designs tend toward functionality and not aesthetics. I modeled this process for our workflow based on a multi-screen wizard. There were points where a user had to choose a content type for instance, and I opted to use a <option/> dropdown whose value determined which screen you'd reach next. Very functional, but apparently not very nice on the eyes.

My designer, who is more of a partner so I can't just run over his opinion, wants to replace this step in the process with a "rounded rectangle," whatever that means. Instead of my functional dropdown, he wants that screen in the process to be replaced by links which, when clicked, advance to one of two screens. So IOW, instead of a field that sets a specific content type, then making nextScreen return a different screen based on its value, a set of links that select the type and advance immediately, no next/back/cancel buttons.

I'd very much like to stick with the wizard-style elements if possible. That is, I like that Lift retains state throughout the somewhat complex submission workflow we need. I like that the URLs are randomly generated. Since step 1 of the process explicitly requires users to agree to CC-license content, I like that they can't just bookmark and share a URL for step 2 and bypass the agreement.
Is this possible? Can I have step 1 in our submission process be a traditional screen, step 2 be a page with link-based decision paths, and step 3 be another traditional screen for collecting specific values based on what was chosen in 2? Or am I so far beyond wizard at this point?

Another challenge I'm about to face is that I'm using screenTop on one screen to display a user agreement, which must be agreed to via a Boolean field. This returns an xml.Element, but it looks like all of the template retrieval/run methods return NodeSeq. Ideally I'd like to place the text of this agreement in templates-hidden. Is it possible to render the contents of a template/NodeSeq as an Element, or might it be worthwhile to create a screenTop method that returns a NodeSeq as well?

Thanks a bunch.

[Bryan Hunt]

On Tue, 24 Jan 2012 11:36:59 -0600, Nolan Darilek <no...@thewordnerd.info> wrote:
> I'm working on my first serious Lift app that will be deployed to
> production. As such, it's my first time working with a designer.

Don't let him near the code. Get him to give you annotated, sliced
photoshop files, with documentation about stuff like relative proportions of
components, color and font properties. AKA. A design brief.

He should have already produced this stuff for your client (brand and interaction
design specs, color swatches, icons, background images).

If you leave him to dick about with your code, kludge is guaranteed.

If you've got the luxury of a front end developer, get him to merge it
into your existing system.

Don't ever let a designer who doesn't understand HTML etc mess about
with code, it just causes frustration for all concerned.

Regards,

Bryan Hunt