 I realize that it's the end of the day and you're all like zonked and so feel free to stand up and like just do you know some quick stretching or something beforehand and we'll get you sent off to dinner and once again there are lots of seats up front so if you you know have bad vision you just want to be a little closer you can see my emotive expressions better come on up okay hopefully you can hear me all right I think we're good to get started here so welcome thank you all for coming I'm gonna talk about some wire framing if you have never touched a wireframe before that's totally cool we'll keep things pretty foundational but hopefully you know even if you're doing this daily you can learn a little something get get refreshed my name is Garrett Voorhees I'm a senior designer at chapter 3 out of San Francisco and part of our design team there go check out our website I suppose wireframes wireframes so why why do we make wireframes this should be a poem you can explore iterations really quickly with a wireframe which is something you can't do if you're producing you know super high fidelity visual design comps it allows you to focus on usability before you worry about those design matters it can serve as a technical reference for your developers which is often really important if there's any sort of handoff from you know your role doing UX or wireframe stuff and then you know a developer might pick that up months later and need to kind of figure out what's going on or what the structure is and how they're going to build from those wireframes it saves you a ton of time and effort and what I mean by this is it's easy to to go in this kind of endless cycle of you know feedback loops with a client and if you can iron out kind of these early structural decisions and get that like signed off it can really save you a whole bunch of hassle they're also extremely testable and this kind of you know relates to the usability you can get a few people in a room print out your wireframes on a piece of paper or help just you know sketch them on a piece of paper and very quickly assess how successful they are how effective you know the the workflow is whatever it is that you're testing so why why shouldn't we just like dive right into design it's it's a really tempting thing to to want to just jump in and you know I've done this before and usually it doesn't really work out but sometimes you'll have just this mental image of what the site should be and it's in your head and you want to just like get it down you know on on metaphorical paper but you could go that route and make like an insanely beautiful comp it looks perfect and then the next day your client changes requirements and all of your work is you know effectively obsolete or partially so don't be that guy stick with your wireframes so we we at chapter three seem to love this analogy that building a website is like building a house so I like to say that wireframes are kind of the blueprint of your website and so this is just a side note blueprint schematic of the Tower of Terror which I thought was kind of cool-looking and it serves for a nice visual but so here's your header here's your your primary navigation your carousel sliders etc these are all pieces of you know this whole structure and so the wireframe serves to kind of communicate the relationships between all of these different components of the website and you know once again if if your developer who is I guess a construction worker in this analogy they're going to use that as a reference very likely when they're you know building your house or website so I want to like stress this repeatedly that paper is like probably the most critical tool that I work with when producing wireframes and so today I'll be talking to you about kind of the process that I follow at chapter three which is truly like my process it's not you know the way to solve every single thing and there are tons of different software solutions out there now but paper is kind of like universally a good and helpful thing you can crumple it up and like throw it away very easily you can you know iterate rapidly lately I've been using a large kind of 11 by 17 pad of graph paper you can just use scraps of you know printer paper whatever you've got lying around but I always like without fail start on paper and force myself to kind of work through the the first stage of the process on paper seriously so you can meet your your new best friend here is a humble box this is the the kind of friend who would like move you into a new apartment and he even has a little friendly face so I use a box you know very liberally when I'm sketching out wireframes it could represent an image it could represent you know a chunk of the page that I'm going to fill in later that I don't quite want to think about yet so often my my first pass on a wireframe for a given page could be you know just a series of these boxes and you know I label one like header sidebar main content footer and that sort of thing and that can get you just thinking about you know how are these things relating to each other what are the general proportions and how how should they be you know harmonized and then I'll kind of add increasing fidelity as I work through these so I want to show you some examples and I basically wanted to show you how ugly my wireframes often are and how that's a totally good and cool thing so these are live you know real-life examples of wireframes that I've used on client projects in the past and you'll get to see kind of some variety in the approach and then we'll step you through it so on the on the screen here you're seeing you know a basic news page I didn't bother writing out you know all the list items I've got a big box for like a featured area I know I'm gonna have some stuff in the side bar and like this is enough for me to look at this page and start to feel out you know is this working is this starting to communicate everything that we needed to communicate and I should clarify that up until this point I would also have been involved in the strategy on this project typically that's the way we usually work at chapter 3 so we've already defined goals for this page we know you know who the primary audience is what the key calls to action would be what all of those kind of what we call content buckets the main kind of chunks of content on the page I have some sense of what needs to be accounted for and so once I have a wireframe it's serving to kind of start figuring out that hierarchy of information so you can see here going from paper to digital it's pretty similar it's not you know super different you can see all of these critical elements I still have you know a box in there and then here is the you know the the final live page and you can see that next to the wireframe and once again things didn't change you know all that much visual styling has been applied color typography images all of which I try to keep out of my wireframes as much as possible so here's another one basic you know ugly little paper guy and you'll see that I often take little notes in the margins I kind of draw arrows for things if I forgot something it's okay just like you know make yourself notes for later a lot of times to you know projects can be put on hold they could be drawn out it's it's good to leave yourself those little notes for your future self so that you can pick this up months later and remind of you know be reminded oh that's that's what that's for or I often use that space to often make myself you know suggestions like try try a different layout here that sort of thing so here's some some just details of a few of those guys and then once again we've got the digital wire next to the paper structurally it's all doing the same thing and then again the final page next to the wireframe let that soak in for a second so here's a more recent example on graph paper and you can see I made a ton of notes kind of in the margins and you know like try this thing differently here or this content should be this consider using you know a different format here or whatever it's whatever is useful to you and side note graph paper totally rules for this and then the digital next to it and in this case this was for a tablet instance so we have some tablet ease stuff and then the final comp next to the final wireframe so I'll say it again you know a few little elements moved around but on the whole you can see that the core structure was maintained throughout the process here's an example from the the same project where I was looking at some different ways to approach the primary navigation in that same tablet state so again paper is a great way to try out some different things very quickly you can have these things next to each other and like you know compare them side by side show it to the person next to you like does this make sense would you know where to click and it's it's super easy to just very quickly work through that and then here's what you know the the design comp ended up looking like and you can see side by side that the sketch you know reasonably translated to where we ended up we ended up dropping icons and some extra text and things but it was a valuable you know step to be working through paper and another one showing a mobile home page so you know if you don't have enough room in one column like mobile pages get super long I will just kind of you know continue it in the next column and in this particular case we've been trying some different things at chapter 3 because you know increasingly our sites need to be responsive and accounting for that used to be like make a wireframe for every state for every page so if you're doing you know desktop tablet mobile to to simplify it you ended up you multiply everything you know by by two or three so in this case I did paper wireframes and then sat down and collaborated with one of our developers and we built a live HTML responsive prototype that was able to go you know directly from paper to prototype and we've had a lot of success doing this so far it's definitely not relevant for every single project but you know it's working out so here's kind of the the HTML prototype that we built and you can see just kind of it's really simple in this case we were just adding some responsive states to an existing desktop site so they already had like the basic styling taken care of we didn't have to worry about that so we kind of inherited that on mobile and it worked out and then here's just a few other examples of just showing you know it's just really sketchy you don't need to have any sort of drawing ability to produce these things this should be ever present in the back of your head like keep it simple the purpose of these wireframes is you know not to communicate the beautiful design of the site it's meant to you know very pragmatically communicate hierarchy of information what's on the page think about you know if you could show this to somebody would they be able to surmise the basic functionality of that page and if so then that's great so I like to say your wireframe should be ugly but more accurately they should be ruggedly functional think kind of more more Hemingway and less Dickens you know keep it very concise be as brief as you can just strip out all that extra stuff because it you know becomes extra visual noise clients react to that it becomes a distraction so this is kind of the the billboard for wireframes you might have seen this if you're coming in from the airport just use Helvetica and call it a day like why what are you thinking you know just just use Helvetica unless you know your client may have a very particular typeface that they use that's so strongly associated with their brand that you know their eyes would burn if they look at Helvetica in a wireframe otherwise just just use this or use comic sans if you're using balsamic and you don't know how to change the default you might end up with some wireframes that look like this which is also totally fine the other thing you need to be careful of is making sure clients understand what a wireframe is so maybe you've run into this problem where you know oh I made this beautiful wireframe and the client's like what what is this this doesn't look good this like this is not acceptable our website can't look like that so it's important to manage those client expectations and you know set them up for what what they're going to see so that it's not a big surprise when they see something that's all black and white with some blue links and comic sans or Helvetica also important don't let yourself get married to like layout decisions that you make during the wireframing phase you are establishing structure but like it's pretty inevitable that you know once you start making it visual and applying more styling you're going to change your mind you'll think something that was a great idea you know a few weeks ago no longer really works in practice so it's important to kind of be flexible as well as long as you're not you know throwing everything out and screwing over a developer who may have started building the site we occasionally will start building sites from the wireframs while the visual design process is is still ongoing it depends on you know the nature of the client and our timeline and all those factors but that's that's also a possibility so related to kind of keeping things simple you really want to just minimize your color palette unless you have like a really good reason for it to be in there like I was saying any extra noise just becomes you know other possible points for feedback which can be unproductive at this point in the process and if if the discussion starts kind of going off the rails a little bit you know you can ask your client like is this layout communicating the correct content hierarchy and use you know big words and make them feel intimidated no don't do that but say you know just is this wireframe representing all of the functionality that needs to be accounted for on this page and you know those are the ways to kind of have more productive discussion about wireframes so likewise use color to communicate functionality you're not using color at this stage to you know communicate a mood or a tone or you know emotion I'd say you know make your links blue like the default that beautiful blue that we all know if you have something like a cancel button or like a delete function something like that on your page you know use red otherwise just stick to black and white if you're putting any photography in there it's helpful to like you know make that black and white depending on your tools like in in adobe fireworks which we happen to use for a lot of stuff you can just apply a style that will make it grayscale and then when you're ready to move to your visual comps you can you know delete that style and you're all good so here's a few comps that kind of visually communicate how how this use of color is pretty effective you can look at any of these and you know where the links are on these pages it's like no question and likewise for things like buttons or you know some of these delete links and that sort of thing like it should be abundantly obvious where all that stuff is falling now if it's possible it's great to use real copy but that's not you know really realistic a lot of the time so don't be afraid to use placeholder stuff it's important though to kind of estimate the the general length of how you know what the copy is going to be eventually so that you're not putting in paragraphs when it's going to be you know a two-sentence blurb and that's where it's it's really on you to start thinking about that and to to offer some guidance to your clients too because they their instinct is often you know they have this huge page of information and it all needs to get crammed in there but this is an opportunity for you to say hey if we can cut things down be a little more concise you know it can actually make this page much more effective and then your wireframe can become a visual tool in that sense to kind of reinforce that so there's a great site which you may have seen called meet the ipsums and you've seen I'm sure classic like lorem ipsum text but sometimes you know you get tired of the same lorem ipsum sit to lure Latin stuff so this is a tiny selection but there's there's a Sagan ipsum with you know Carl Sagan phrases and bacon and skateboarding terms and the site has a whole bunch of like mostly goofy but somewhat legitimate terms a few of my favorites you might not have heard of this one we've got hipster ipsum and actually my personal favorite is riker ipsum because these just tend to be really cool phrases I'll let you read those for a second although to be fair like the reason lorem ipsum is so effective is that as non-English text we don't tend to try to read it so it doesn't become a distraction you know if you have real copy in there or even if you if you write some fake copy that's like just plausible enough to seem like it might be real clients can get very distracted by that too and we've we've definitely run into that before so there are like multitudes there's a whole universe of software out there I happen to use Omni-Graphel once I'm moving from paper to digital so I'll talk only briefly about you know how I use Omni-Graphel but I think it's a great tool if you are just kind of getting into this and want something to try out I think it makes things pretty easy we also use Omni-Graphel to build out all of our site maps before we get to this point and it's just easy to kind of make you know flowcharts and that sort of thing it's pretty awesome so here's kind of your basic here's a wireframe document you can have multiple pages you can do you know basic styling fill stroke whatever all the stuff that you would kind of expect alignment tools but the the best part about Omni-Graphel is probably stencils and stencils are like the biggest time saver that I can imagine so these are effectively pre-built little elements that you can you know drag and drop into your document so it's things like forms or like a little calendar things that they're kind of annoying to mock up on your own different like UI elements icons and that sort of thing and there are a couple sites that have you know good libraries of these things so graphotopia is kind of the biggest one and I recently heard about stencils.io so graphotopia was free for a really long time and it was super cool it's still cool but you have to pay for it you get like one free download per month which is really kind of meager unless you you want to portion out your downloads throughout the year but for like two bucks a month you get access to a really big robust library they have some like individual kind of fancier stencils that cost more you know in the in the scope of like a typical project budget this is like absolutely zero it's almost like in zero cost but it is a cost but they have a big library high quality stencils has a more limited library but they have some really good stuff too they're basically just aggregating links to pre-existing free omnigraphal stencils that are online you can you know search and browse and they've got categories and stuff in graphotopia stencils doesn't but it's basically one page you can just like scroll through it pretty quick and yeah graphotopia has a lot of stuff that you can find elsewhere if you want to dig for it and no no account for stencils so here's a couple of the stencil packs that I typically use that I found to be most useful this konigui one is like kind of my gold standard or used to be and this is just a sampling of some of the elements that are included but you can kind of get a sense it's got you know a bunch of different button styles and like checkboxes and radio buttons like a little whizzy wig and tabs and all of these are built you know in omnigraphal so you can resize them and it's like very friendly to that sort of thing so this this kind of stuff saves me a ton of time if I'm mocking up any sort of page that has form fields or any you know anything like this of course there's a Twitter boot strap one which is what you would expect to kind of all of our basic Twitter bootstrap elements all those great little icons so you can like drag them right in it's effectively you know the same thing but just with the the Twitter bootstrap flavor applied to it and there's also a Zerb Foundation if you happen to dig Zerb Foundation or are already using it or just like the visual style of it this one kind of functions the same way and they've got you know drop-down knabs and carousels and all this good stuff so here here's just a quick example of in practice how you know one of my wireframes that uses these stencils might look so I've got a bunch of I think these are mostly the Konigie ones or now these are Twitter bootstrap but this page is like 80% stencils and then some text around it and it's really quick to throw these together so I'll speak really briefly about other software but and these are just a few of them I know there was a presentation on Aksher earlier today some people are you know very they swear by you know this or that but really it doesn't matter what you're using a lot of the software is not intended for wire framing at all like in design or even keynote but you know they can be really effective tools it's really more about following kind of the the basic principles of building these things than it is you know finding a tool that can do every single fancy feature that you need although those are great too so let me kind of sum up some of these key bullet points paper is extremely important you should always keep it simple keep things ruggedly functional like Hemingway minimize your color palette don't be afraid to use some placeholder copy and Omnigraphil is pretty cool but you know if you have something better go for it and so at chapter 3 I will often take a an old like wireframe template that I made for a client and then I'll just do a save as and like modify things from there and it's a really fast way to kind of get things up and running I don't have to worry about like building this out again so last year I put together a wireframe template that you can go and download and it covers just some basic pages it uses some of these stencils but you can open it up and kind of pick it apart and see like how one of these documents might be built and you know save it out yourself and then mess with it so it's got you know a basic home page although at this point this is this is based on our old website but that's fine it's you know a generic blog sort of thing got like a blog post and so you can go on and it is available for download and thank you for asking it's available for download right here tiny dot cc slash c3 wireframe and it's free but I mean and truly like it's it's very basic but it's a good way to just start looking at this and thinking about it and like picking it apart a little bit oh no if you go to the chapter 3 website and you find my blog post about wireframing in Omni Graffle there's definitely a up-to-date link there I thought that this guy was still alive that's okay I'll tweet it out too after this session but you know what that's that's what I have to kind of talk through right now I would love to kind of spend more time taking questions and like talking more about kind of workflow in more detail so I guess you should probably go up to that microphone so we can all hear you because this is being recorded and if you ask a question or honestly even if you don't we've got some free goodies up here so yeah all right besides the templates that you provided that will probably provide a pretty decent foundation for different sites home pages and even different sizes of like responsive I imagine mobile and desktop if you need to build something from scratch and it does have to be for desktop and mobile is there a software that can kill two birds with one stone or do you always just end up doing you know I guess almost twice the work or something or what do you recommend sure there there is software that does this I mean McCaw is now out and that I haven't had the time to like dig into it and I believe actual also lets you build you know a responsive prototype in I haven't actually worked with those like I have made separate pages in my Omni Graffle document that are like the mobile state and so it is like a little more time-consuming but the fact that you're using things like stencils allows you to put those pages together really quickly so it still eats some time but it's not it's not as bad as you might think and you're able to kind of duplicate things and reuse them fairly often so yeah my question is why did you pick Omni Graffle what are some of the strengths and how does it compare with balsamic sure so Omni Graffle I just kind of happened to pick it up I don't know that I'm trying to remember how I first used it it basically was straightforward enough I started using it for site maps and what I like about it is it's easy to kind of select a lot of elements and resize things and move them around and previously I should also clarify we were using fireworks to make all of our wireframes before and we still do occasionally if it's like a little bit more high fidelity but Omni Graffle was just really fast I would say some of the drawbacks it can be a little janky sometimes like the interface is not the best but the stencils were like kind of the killer selling point for me because that's you know the bulk of a lot of this work and being able to just drag in those elements is hugely helpful yeah I think at one point I did I don't know 50 or 60 wireframes in like a couple days thanks to the magic of Omni Graffle and the stencils I'm going to embrace the paper prototyping model and yeah the challenge I'm finding is that I'm sketching alone in my office it's hard to pipe those over to the client to get feedback because everything you do needs to be explained to them and you talk to you all the options and get their feedback how do you work that into your workflow as far as I guess scheduling regular meetings with them or how do you not let that lack of communication interrupt interrupt your own workflow sure so in our case like I'm never showing the paper wireframes to a client actually that's that's pretty important or very rarely if I'm doing something like a paper straight to an HTML prototype then like we might discuss that with the client and I would you know just shoot them with my iPhone and like upload the photos to Dropbox from my phone and that that's been like reasonably fast for me there are I'm totally blanking on the names but there are apps where you can take a series of pictures and you know effectively build a quick little prototype just on your phone and you set like the areas and you can say this tapping this area of this photo links you to this next page so those exist and that that seems when you you share your paper prototype with your co-workers basically right yes their sign-off is basically enough for you to move to the next level yeah okay we have done paper I guess more directed with the clients it's less frequent for me I mean there's a whole range too if I see I'm struggling with a difficult client yeah we have once a week meetings and they're like I don't like the design here and I'm like I'm here to talk about UX I'm looking for a good example for you here so like this one I wouldn't show to a client unless we were like BFFs because I just think that this this isn't as productive but honestly like working on graph paper I can make these things look pretty sharp and everything is like really you know clean and and marked out so it can be like pretty legitimate yeah I just want to get more with when you're presenting your wireframes to users or clients I think especially if it's a new project I find sometimes because it's for your users their first time seeing anything it's the first time their ideas are coming to life and so some of the conversation is certainly layout related they might be like yeah I like this but then often the conversation goes totally into different realms of functionality and all these other things and it's useful conversation because I think the first images spark it but how do you manage it so that you're getting what the purpose of the wireframe is without losing this other information I mean if you ask like very direct targeted questions like is this page doing you know this particular thing and if if you do that rather than just putting it in front of them and saying like what do you think then it tends to be a little more productive I mean they still will get sidetracked and it's totally okay to say like you know this isn't really the point in the process to talk about that like well you know we'll get there in a few weeks when we're doing like visual comps or something like that I don't know what what sort of question you said that they're still productive well I guess maybe sometimes like a new insight or something that like has not been in the discovery process might come out and you want to make sure that doesn't get lost in the lighting like okay well that's a bit later in the process but you also want to make sure it doesn't get lost at the same time yeah I mean for those things I just tried to take a note of it and like remember it for later but I mean sometimes that is really important too yeah or like if I do have live relatively live copy in the wireframe and they're like oh you know now that we see this in a like a page layout we want to you know edit this copy or change these words like that can still be a relevant and productive discussion even if it's not directly related to the wireframe so I guess you you don't need to be like hyper strict about it too maybe that's helpful you said that you're involved in most of the process leading up to the wireframe process as well I was wondering if you could give like a brief synopsis or understanding of your architecting process or maybe just a little bit about your discovery process just to understand what happens and up until this point yeah yeah absolutely so the the kind of functional requirements would already be defined before I'm involved you know that's handled in kind of the sales process but I'm I'm usually there for the kickoff and we work through we send our clients a strategy document that they fill out that covers you know what what are the goals of this site what are kind of your tactics it covers a you know if if your website were an animal what kind of animal would it be and that kind of thing where they can start generating adjectives that we would then use later so that gives us kind of a foundation from there we usually go through personas and we talk through the main kind of audiences on the site and build out personas for each of those distinct audiences so then we're defining goals for each of those personas and that gives us a little more information from there we build a site map so we know what the general you know information architecture will be for the navigation of the site and at that point we're identifying which pages we expect to be distinct design templates because you know we're not going to design every single page on the site from there we do page tables which are looking at those template pages and making defining the goals for those specific pages and also defining what the main chunks of content need to be on those pages and that that page tables document is what is most relevant to wireframing because that's what I kind of have as a reference to make sure like are we including everything first of all and then is it kind of in the right order and you know represented with the right hierarchy so then we produce wireframes and then we go off into you know the visual design and do mood boards and like visual comps yeah and it is kind of rare that like in our case it's one individual who is covering that entire process up until it's like handed off to a developer so I realize that's kind of sometimes atypical um in my experience I've often seen that a wireframe kind of the functionality that's defined there gets lost in translation by the time a developer gets it at chapter 3 what do you guys do to make sure everybody stays on the same page before you know any time is wasted we we totally struggle with that too and we have we always kind of try new things to see like maybe this will get us there a little bit closer I will include like annotations sometimes in the wireframe which you could throw you know throw it in there in like hot pink or something and just add a little bit of text so you know that that can provide some reinforcement we will also build you know have like a centralized Google doc that spells out all of the different functionality and kind of our expectations for how those things would work so you know something like a carousel slider could seem super simple but there are lots of variables that go into it is it going to auto advance like what what's the duration of each slide or you know how many do would we cap it at so we try to kind of like define those things as well in like a document it can still get glazed over and it's easy to miss and you know sometimes more complex functionality just can't be communicated in a single wireframe so we also do a handoff with our developers at whatever point they're starting development we sit down with them and walk them through like as much of the project as is reasonable to make sure that they have an opportunity to ask questions and you know we can clarify all that stuff so it's it's really about the communication I would say more than anything it's not like one particular tool or something that solves it for us when that functionality is then ready are you the one who tested to make sure that it matches what was on the wireframe or yeah I mean ideally it again it doesn't always happen we try to make it happen that the designer stays involved with the project you know as it's going through the development process and we encourage our developers to keep you know really open communication with you know our design team so that we can see how it's coming along or if they have a question about something like they just you know will ping us at any time and so that that seems to work out pretty well for us too yeah any other brave souls I'll just kind of chill up here too if you're if you're a little bit shy about going up to the mic or you can shout it lately it's okay so that the question was when do we decide when we actually build a prototype versus you know going a full digital wireframe route it's kind of a recent thing for us but it's been projects where there's like an existing site and we're just kind of extending it and we know that like we kind of understand what all the functionality is already do you have anything to add to that I mean it it's kind of hit or miss yeah yeah if it's like a heavily responsive site where we want to be able to you know test it on a device that's that's helpful too we're doing it kind of more and more though and I'm having enough success with it that I I want to like continue doing that you know right now it's it's exclusively for like responsive sites though if it's just a desktop site I don't think it's really worth the time currently that's what we're doing yeah and even you know the HTML prototype isn't even built in in Drupal it's just kind of its own little standalone thing yeah yeah thank you you're reminding me of things that I probably should have mentioned earlier but when I'm working at Omnigraffle I tend to not use a grid which sounds maybe silly but it's important to me at that stage to keep it really loose so if I know it's going to be like a three-column layout I kind of you know I'll make them each even and evenly spaced but I'm not strict about getting like things pixel perfect at that point it's more about the the general idea of the page so it does introduce more work because I have to recreate things from scratch when I start building my comps in fireworks but to me like we used to do a wireframe in fireworks and then just save as to our design comp and you get lazy and like you it doesn't challenge you to like rethink about the the layout necessarily like it's important to not change the structure a bunch but it's also important to have the flexibility to try some new things at that point in the process because that's when you're doing the the real creative work so yeah there is like a little bit of extra effort required but I like keeping it separate it's like the same way you know you want to keep your home life and your work life separate or something like wireframes and design kind of live in their own castles you got to travel between the two that's a it's a weird analogy any other questions yeah good question yeah so the the drop of firework support was a crushing blow to us although honestly fireworks still works fine and it will continue to work okay I've been using sketch from bohemian coding and I've had some success with that it feels pretty nice it's not quite there yet there's like some critical features that are still missing like exporting documents is a little goofy you can do you know like global styles but you know it's it's definitely getting there they seem to be the strongest contender for like a pure fireworks replacement but for the time being we're we're still using fireworks really heavily I don't think adobe is going to change their mind or anything but you know we go and pick at their offices every Thursday there's like five of us that really like fireworks actually there's a whole group in the bay area like a meet-up group of fireworks users okay I'm gonna cut it off here feel free to come up and chat thank you all for coming