You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2014-03-31-eng-happy-hour-sergey-karayev-talks-deep-learning.markdown
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Sergey is a PhD candidate in CS at UC Berkeley, and works on artificial intellig
9
9
10
10
His talk was really cool, and opened up a lot of questions from the team about what deep learning really means, and whether guess and check is a valid scientific method. We got a lot of requests from those who couldn’t make it to post slides, so [here](https://dl.dropboxusercontent.com/u/44891/research/computer_vision_and_deep_learning_feb_2014_at_prismatic.pdf) they are.
Since we wanted to experiment without forcing all our existing customers to live through a rapid and peculiar sequence of changes, we put the new grid design up on preview.getprismatic.com
Teehan+Lax has [written up](http://www.teehanlax.com/story/prismatic/) the detailed design process that lead to all aspects of the grid design, nav and other screens in Prismatic, so we won’t do that here.
21
21
@@ -41,11 +41,11 @@ Before investing time in designing a universal list layout for all screen sizes,
41
41
42
42
We’d like to do this as quickly and cheaply as possible, isolating the change to ensure we aren’t confounding variables by introducing too many concurrent design changes. Preview web’s grid view had three grid units per row, so if we merged the items in each row to form a three column list item, we could test a list view. This would be a mediocre list view design, but if it outperformed the grid, then hopefully a more thoughtfully designed list view would as well.
Before looking into the methodology and results, recall during this testing phase we have three versions of the web product running in parallel: 1) the old list view (old web), 2) the preview grid view (preview grid), and 3) the preview list view (preview list). Preview grid is the version of Prismatic we worked on with Teehan + Lax.
Importantly, there was a stalwart group of Prismatic users continuing to use old web, entrenched in their desire for a list view. We wanted to test how the preview list design performed against both users of preview grid and users of old web.
51
51
@@ -84,7 +84,7 @@ Our first step was to introduce the preview list design to 20% of users on previ
84
84
85
85
To elicit feedback from old web users on preview list we emailed a sample of users who had logged into old web 15 of the previous 30 days. We received 68 responses to our survey indicating that more than half of the stalwart old web users would now be willing to switch to this new list view.
To our surprise, when evaluating the numbers from the 20% of users on preview grid who had been switched over to preview list, the results were significantly better. We wondered if this might be due to a novelty bias, and so we waited between rolling each new cohort on preview grid into preview list. We increased the proportion of users on preview list by around 20% every week or two until all users were on preview list. The performance gains held stable over many weeks and remain stable today.
90
90
@@ -141,28 +141,28 @@ Given the surveys, metrics, and our past feed design experience, we laid out our
141
141
142
142
In the past we’ve made the mistake of designing one platform at a time, which yields excessive churn as you discover new things on each platform and loop back to redesign the previous platforms - designing universally with screen characteristics rather than ‘mobile first’ was critical for us this time around. Mobile first creates churn, now we design ‘universal first,’ aiming to develop modular systems that maximize the experience on each screen, rather that churning as we jump from to screen to screen always yearning to redesign the last screen after finishing the current screen. Here’s a look at the results of this process.
This time around, we’ve designed a system that works well on all screens. We looked at a few important points. Designing for Android, which means things need to be flexible within ranges of screen sizes due to the vast number of screen dimensions - even if you have some discrete settings, you can’t make everything absolute as is the case with iOS. Designing for mobile, especially tablets, implies thinking about both portrait and landscape, and you hopefully want to think about reusing portrait layouts on larger screens as landscape layouts on smaller screens. We had to create unique layouts for phone portrait and phone landscape, but we were able to reuse web small as tablet landscape. So in the end, we have 5 discrete settings; phone portrait, phone landscape, tablet portrait, tablet landscape / web small, web large. The only setting that differences in content layout rules is that on phone portrait, we do not allow two columns, so images can not appear to the right of body copy.
147
147
148
148
You can see the first iteration universal feed layout in production [here](http://preview.getprismatic.com), and a look at how it responds to different screen sizes below.
We also intended to design our universal feed to accommodate what we can interstitial and rich remove story units. These are examples of non-article story units that can cause some problems in some settings, but work great in our new list.
154
154
155
155
Interstitials are a way of visually calling attention to a story unit other than a typical article type, for example, if we want to suggest some topics we think you’ll be especially interested in. We want to ensure that we design a feed system with interstitials in mind. The great thing about list layouts are their inherent row-based flexibility. Since there is nothing to the left or right of each unit to align with, it is hard for the system to fall apart when you introduce new components like interstitials.
Rich remove is a feature that allows customers to help us improve the quality of results they get. When a customer dislikes a story with thumbs-down, we can overlay the ‘rich remove’ model on the story, which allows the customer to block topics, publishers, or people, or tag a story as having certain undesirable attributes.
With our universal list accommodating all screens and story unit types, we were ready to test it out against our recent feed design for [iOS](https://itunes.apple.com/us/app/prismatic-always-interesting/id551206444) that we shipped in late December 2013. We decided to test this on an iPhone against our new universal feed layout, also on an iPhone. We did a round of internal critique with everyone in our company, comparing our latest iOS feed design with our new universal feed design. Then we did a think-aloud study to see what people thought upon seeing both our latest iOS feed and new universal feed design.
The feedback from the internal critique was that the new feed looks better aesthetically, the topic tags are cool, the bigger images are great, the separation of stories was unclear, and some of the explains were unclear.
168
168
@@ -174,11 +174,11 @@ The next biggest issue was confusion with topic tags and explains, so we designe
After generating a few options, we surveyed the team to get feedback on the design of topic tags and explains. We found unanimous preference for adding a check next to the topics in tags to show you follow them as opposed to changing the colors of tags or adding the stroke border. Explains were generally well received, but we found some confusion with the ‘hot’ explains, as well as authority explains.
184
184
@@ -188,4 +188,4 @@ We decided to ship with the check model of indicating following on topic tags, a
188
188
189
189
We’re happy with where [we’ve ended up with the new feed layouts](http://preview.getprismatic.com). It brings together the best of what we’ve done across different generations of design on both web and [iOS](https://itunes.apple.com/us/app/prismatic-always-interesting/id551206444). The design is fully responsive and works great on mobile. There are a number of issues, but we know we’re following a path that’s validated by metrics and user studies, and we think this is a foundation we can build upon in small increments rather than big redesigns. Designing a simpler and more universal system can be better for you, and better for your customers, so move carefully and with data before jumping into big redesigns with more complex layouts.
Last Wednesday, we held our first ever Clojure Community Night at Prismatic to encourage and connect with the Clojure Community. We’ve included CTO [Aria Haghighi’s]() talk on what Prismatic is doing to improve the Clojure Community and areas where we think there is room for improvement.
Copy file name to clipboardExpand all lines: _posts/2014-04-08-graph-abstractions-for-structured-computation.markdown
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@ In this post, we want to focus more on how Graph can be used to reduce complexit
33
33
34
34
Jason Wolfe's [Strange Loop talk](http://www.infoq.com/presentations/Graph-Clojure-Prismatic), [slides](https://github.com/strangeloop/strangeloop2012/blob/master/slides/sessions/Wolfe-Graph.pdf?raw=true) and subsequent [blog post](http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop) last year covered two concrete real-world examples of Graph from our codebase: composing production services, and generating personalized newsfeeds in real time.
Copy file name to clipboardExpand all lines: _posts/2014-04-08-prismatic-is-getting-social.markdown
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,11 +7,11 @@ Right now you can follow topics and publishers on Prismatic, but we’ve always
7
7
8
8
If you’ve been a longtime web user, you may have noticed that the old share counts in story headers have been replaced with counts of Prismatic social actions.
Today, we’re launching a newly redesigned profile with cover photo, avatar, bio, and the ability to publish your recommend, save, read, and interest actions to both Prismatic and external networks.
Copy file name to clipboardExpand all lines: _posts/2014-04-08-prismatics-graph-at-strange-loop.markdown
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ And if you're exited about working with us to release some great (soon to be) op
11
11
12
12
Software engineering is very important to us at Prismatic. We've written about our fondness for [fine-grained, composable abstractions (FCAs)][swe]. However, in a number of our real systems, we've relentessly refactored and modularized according to these principles, but still found ourselves left with complex top-level compositions like these:
At left is our production API service, and at right is our real-time newsfeed builder pipeline. As you can see, both are large networks of many components connected in complex webs of dependencies.
@@ -36,7 +36,7 @@ Or, suppose that we want to monitor the individual sub-computations in this func
36
36
37
37
The basic point is that using large `let` statements to describe complex compositions can lead to verbose code that is brittle and difficult to debug, test and monitor. The core issue is that while as programmers we can see the individual components and their relationships, the rest of our code and tooling does not have access to this information because it is locked up inside an *opaque* function.
For example, this graph shows the nodes and data flow in our `stats` function, which is invisible from the outside (i.e., without examining the source code). Graph is about making this structure explicit.
Within a day, this small incremental list view redesign gave us sufficient evidence that investing in this path was a good move. This is a great example of how design and engineering working together in clever ways when taking implementation considerations into account.
116
116
@@ -132,30 +132,30 @@ Once we’re going from the early design goals and inputs to getting started, we
132
132
133
133
We often kick off a new direction as a team with short sketching sprints to generate ideas as broadly as we can. We do a few 10–15 minute sketching sessions with rounds of discussion in between. The goal is generating as many ideas as we can, exploring divergent themes and covering as broad a territory as possible. We ignore constraints to ensure we’re going as broad as we can. During the discussion between each sketching sprint, someone takes notes, including noting the best concepts in each round of discussion. Then, we discuss them all as a group and narrow down to a few options we want to wireframe.
After we choose a few directions that best satisfy our goals, we start to explore them in wireframe fidelity for each option. We explore visual layout structure using mock text and images, and without meticulous pixel detail. We also use the goals and inputs to reason about which directions seem to be working better and spend more time iterating there.
140
140
141
141
We’re big fans of ‘exploration maps’ - infinite canvas artboards in Sketch. When we’re in this stage of exploration, we simply take the artboard we’re designing in and copy it to the right as we iterate, leaving a quick note about the reasoning behind each step. This way, we can see a clear line of reasoning as to why certain elements are styled a certain way or why they’re placed where they are.
After a round of wireframe critique with design and engineering, we start setting up the visual libraries we’ll need to explore our options at a detailed pixel level. We set up the grid, start setting up type size and scale and gather any design patterns we’ve previously designed that apply to the design we’re working on. We value reuse over redesign - we always try to use existing UI elements from other places in the product, not only for consistency, but for ease of implementation. As we’re narrowing in on the details we bring in front-end engineers to talk more in-depth about how to implement the design.
We use Sketch for both wireframe explorations and pixel detail, which saves us some unnecessary translation time. During detailed design, we use the same approach of multiple artboards to document separate flows as we do during exploration. For example, we’ll often evaluate a wide range of settings for type size, spacing, or color. All the same goals, inputs and reasoning apply here, because the concepts all have to manifest in pixels and stylistic changes can have a massive impact on the direct manifestation of the design goals.
155
155
156
156
We also practice what we call ‘universal design’; designing for all supported screen sizes at once. A separate Sketch file uses multiples artboards to show how a screen will change responsively for each supported screen size range.
0 commit comments