This is Jan Miksovsky's Typepad Profile.
Join Typepad and start following Jan Miksovsky's activity
Join Now!
Already a member? Sign In
Jan Miksovsky
Recent Activity
Yair: Thanks for the insight into Hebrew calendars! For the initial implementation, I made a deliberate decision to focus on Gregorian calendars. My assumption is that most businesses supporting users in multiple languages/countries would end up standardizing on the Gregorian calendar. It would be fantastic if someone wanted to improve or extend these components to support non-Gregorian calendars. The Globalize library actually seems to have pretty good coverage of most calendar systems, including the Hebrew and Hijri (Islamic) calendars, so that might be a big help in implementing support for those calendars in these components.
Which of these month calendars looks correct to you? One of the calendars will probably look right. The other two will just look wrong — like they’re mistakes, or maybe not even calendars. Setting aside the basics of which language... Continue reading
Posted Aug 4, 2014 at flow|state
Yury: Yes, these components definitely need to support touch. That's still a work in progress.
I recently contributed a small handful of web components to the Basic Web Components project, and wanted to share some observations on how designing and building UI with web components is going to be pretty different from how you’ve created... Continue reading
Posted Jun 16, 2014 at flow|state
I’ve posted an app that lets you print a free wall calendar that can make your scheduling discussions go faster. This is based on a printed calendar I created by hand for some years now. As I noted in that... Continue reading
Posted Dec 18, 2013 at flow|state
As we pass through the transition from paper to electronic books, the humble book cover seems to have been dropped from important roles in the reading experience. I'm generally a huge fan of Amazon's various Kindle devices and apps, and... Continue reading
Posted Oct 1, 2013 at flow|state
Wouldn’t it incredibly helpful if we had a library of components providing solid implementations for all the common, general-purpose, well-designed user interface patterns found in mobile and web apps? In such a library, how many components would there even be?... Continue reading
Posted Jul 15, 2013 at flow|state
David: Thank you! I'm looking forward to doing more. I might tackle the next one in early March.
I've been considering putting together a video screencast sharing some thoughts on web UI components, covering the case for why we need them, some limited solutions today, the prospects for the Web Components standard, and the principles behind my own... Continue reading
Posted Feb 11, 2013 at flow|state
In many project discussions, it’s been my experience that two calendar-related questions constantly arise: On what day of the week will date x fall? Example: We’d like to make our next release on or around the 15th of next month.... Continue reading
Posted Jan 16, 2013 at flow|state
The last time you had to arrange the furniture in your home — did you create a design first? No. You had a design idea, and then immediately jumped into implementing your idea by moving the sofa and table around... Continue reading
Posted Nov 13, 2012 at flow|state
BZ: By "native" to the browser, I mean all the interactive elements defined in HTML itself. This is basically the elements, and arguably some aspects of other elements with defined interactions. (E.g., an element with a title attribute will generally produce a tooltip). So a checkbox or radio button would count as native by that definition. My complaints are that this set of these native interactive components is very small, and that you can't build first-class components like those yourself (yet).
Just as geometry builds up complex results from simple axioms, and programming languages build up complex constructs from simple primitives, it should be possible to create complex user interface elements from simple elements. But the lack of great building blocks... Continue reading
Posted Sep 17, 2012 at flow|state
Web app designers and developers spend a staggering amount of time recreating common effects and behavior that have already been done many times before on other sites, or within their own organization, or in their own code on previous projects,... Continue reading
Posted Jun 19, 2012 at flow|state
For the past two months or so, I’ve left off from my weekly blogging habit here to focus on some behind-the-scenes aspect of QuickUI. I post about those updates on the separate QuickUI blog. That blog is more technically-oriented, but... Continue reading
Posted May 22, 2012 at flow|state
Imagine, for a moment, that you’re living way back in the early 1980s, maybe 1984. You have access to a computer, and on that computer, you use a top-end DOS app like Lotus 1-2-3: Then, one day, you see a... Continue reading
Posted Apr 5, 2012 at flow|state
yurivkhan: Ack, you're right! That would be a bit of UI history which *I* had forgotten too. I guess I'd long since gotten used to Windows' support for riffing with the mouse up, and by the time I went back to the Mac, they'd picked up that behavior too. Thanks for pointing this out. Rewiring the QuickUI MenuBar control to support mouse down riffing seems like it would be quite hard. Once the user has moused down over a DOM element, I believe it captures the mouse, yes? Which might mean that tracking the mouse over different menus and menu items would essentially require writing a new hit-tracking library to calculate what element the mouse happened to be over. This seems like a colossal amount of work, more akin to implementing drag-and-drop than normal menu click handling. If that's the case, I'm even more impressed by the Google Docs menus than I already was.
The history of user interface design isn’t terribly long, but it’s long enough that designers who ignore it do so at their users’ peril. In the transition from clients apps to the web, a lot of UI history has been... Continue reading
Posted Apr 3, 2012 at flow|state
Ian: I'd agree that not all of these methods are equally useful or usable across all forms of popups -- although all of these are in use, and for each there's at least some context in which the technique is reasonable or even expected. E.g., in a Windows client app, #10 is an expected part of the platform. I agree it'd be weird in a web app for the reason you specify, which is why I left that behavior out of the QuickUI implementation. BTW, I'm not sure I'd agree with a blanket prohibition on having hovering produce a popup. A tooltip is a form of popup whose utility entirely depends on opening on hover. And the menu riffing behavior, in which menus *after the first* open on hover, seems elegant and justifiably used across Windows and Mac OS/X. (I agree that having hover produce the first menu is problematic, and I avoid it myself.)
Apps often need to pop up something over the main UI; common examples would be menus and dialogs. Unfortunately, while apps need popups, documents don’t, and until recently HTML was relentlessly document-focused. It’s frustratingly difficult to do a popup well... Continue reading
Posted Mar 26, 2012 at flow|state
It’s really, really common in UI to place a panel on one or both sides of a main content area, on the left and right or on the top and bottom: As ubiquitous as these layouts are, until recently it... Continue reading
Posted Mar 19, 2012 at flow|state
In just a few years, the ecosystem in which we create UI will change so dramatically that it will be hard to remember how we did things way back in 2012. For a sense of perspective, consider a similar change... Continue reading
Posted Mar 14, 2012 at flow|state
Image-sharing site Pinterest is the current darling of the social media world, and the core of its user experience is its attractively-designed home page: This page takes good advantage of available window real estate. As the user makes the window... Continue reading
Posted Mar 12, 2012 at flow|state
User interfaces invariably entail a certain degree of repetition; they’re filled with vertical or horizontal sequences of UI elements that behave identically are are styled identically. Sometimes the elements in such a sequence vary only in their label, and sometimes... Continue reading
Posted Feb 27, 2012 at flow|state