Tech and Design Blog

Goodbye CMS, welcome static HTML

By Rien | February 14th, 2012 | 2 Comments

We just removed the CMS behind our product site completely and replaced it with a static site. We used to have a static site before, using PHP includes for shared templates like layouts and navigation. However in our latest redesign we added so much content that it helped to have a CMS behind it, for non technical people to update the site. But at the same time it became less fun to update the site for our techies that were not involved in the project before. That’s why we decided to go back to basics. Looking for something simple in Ruby, our beloved language, I stumbled across Middleman. Middleman is a static site generator based on Sinatra. It supports different template languages (Haml, Sass, Compass, Slim, CoffeeScript, and more) and makes minification, compression, cache busting, Yaml data an easy part of your development cycle.

So now we have all the flexibility in the world, it’s easy for everyone with basic HTML skills to update the site, we have version control and simple deployment using GIT and it forces us to make the site compact and maintain less content, which is finally a good thing. Plus the site is super fast.

An intro into developing Viewbook V3: design for agility.

By Bob | January 1st, 2012 | No Comments

Our aim with the new viewbook V3 pages framework was to develop a system that builds on our experience with the current viewbook pages tool, while expanding it’s capabilities with a brand new core setup. In essence this meant we wanted to take all the good out of the current tool, and put that into a new framework that was capable of producing any type of portfolio website we wanted.

When you don’t know exactly what needs to be build, but you have to start somewhere
This latter part was actually pretty important. The thing is that we at viewbook work as a small dedicated team (on average between 6 and 10 people), heavily relying on prototyping, user feedback and, most importantly, our own inspiration to fine tune the new V3 system. This meant we could not develop a custom fit system from start based on a clear and defined set of guidelines (which we did not know yet). But rather we needed a system that could quickly adapt to anything we could think of along the way.

Use things as they are, do not ‘hack’ them
The way we achieved this is by using HTML, CSS and the Web browser (DOM) as much as possible as they are in their purest form, without trying to change or improve them (by hacking around with Javascript). On top of that we designed an XML and XSLT based core framework for page (and module) generation, whereby the configuration for a page is made as abstract as possible. Also the framework needed to be loosely tied to our database environment for easy integration and optimal scalability. In essence this means we can now import any piece of data, ‘capture’ any styling, behaviour or content configuration in a generalized way and generate any type and form of output we want (more on how that works in a later post!).

Developing in this manner might be a somewhat slower approach as supposed to working with a fixed plan and feature set, and it means you might have to wait a bit longer for V3 then you’d like. But it also means we can afford to be really flexible when it comes to implementing new features based on our ideas and your feedback.

Importing plugins, feeds, designs, etcetera
The new system also makes it easy to integrate features especially for developers and designers. For Developers things like easily integrating custom jQuery plugins in your page and using V3 components in custom websites or WordPress (and other blogging environments), plus importing data into a component from any source you want. And for designers the importing and exporting of designs from and to your favorite design applications (Adobe Illustrator, Indesign), making custom design templates manageable by your clients or act as a third party reseller of your designs.

In any case the main focus for V3 will be the components you use to fill and style your portfolio. And each component can be made as exactly as we want them to be. So that will be the part where this flexibility will pay off the most, and where your feedback will be most valuable. But more on that later in our next update!

Viewbook job opening: lead Ruby on Rails developer

By Rien | October 7th, 2011 | No Comments

Viewbook enables creatives to design and manage their own portfolio websites and work presentations, wherever needed; around the web and on mobile devices. We’re looking for an experienced Ruby on Rails developer to join our team and bring Viewbook to the next level.

With Viewbook users can upload images, create albums, portfolios and within the portfolio website editor they are able to manage their work and create portfolio websites with a desktop like experience. In the next version of Viewbook (Viewbook V3) the website design editor will become much more interactive, giving the user options to edit layouts and add many different modules. Together with our iPad portfolio app, and many external plugins, Viewbook is a true platform for the presentation of creative visual work.

Technologies we use
At Viewbook we have a combination of pure back-end services and real front-end Javascript applications. We use several RESTful Ruby on Rails apps with Mysql in a more or less Service Oriented Architecture. Plus a couple of utility apps and a stack that handles resizing and uploading of images. We use EC2, S3 and since a short period Engineyard’s Appcloud. For the front-end we use a custom designed Javascript framework that makes heavy use of jQuery and Backbone.js, plus XSLT on the server for transforming documents to wepages. We vastly prefer open source tools and aren’t afraid to work on the cutting edge.

About your job
You would be an integral part of our team and dive into the Rails apps we’ve developed; to add new features, test and optimize them. You will work closely together with our lead front-end developer to implement and optimize the features that are needed. You will also work closely together with the DevOps team to optimize and scale our apps on an architectural level.

Our ideal candidate would be an experienced (or fast learning) Ruby on Rails developer with strong core Ruby skills to help our development team maintain and expand our webapps, webservices and databases. You need to have strong back-end ability and a love for clean code. Additional front-end/UI ability (Javascript, jQuery, Backbone.js) and a love for Graphical User Interfaces would be great but is not necessary. We’re looking for someone who gets excited about creating great products in a creative environment and enjoys working with a small, highly motivated team.

Required Skills
Experience writing web applications in Ruby on Rails
Experience writing unit, functional, and integration tests; especially with RSpec and perhaps Cucumber
Strong in MySQL
Experience with RESTful principles, HTTP, XML and JSON
Experience with running Background jobs

Bonus Skills
Experience with high-performance apps, scaling and load balancing
Server Administration (Unix/Linux) and cloud hosting platforms (AWS, EngineYard, Rackspace)
Experience with HTML(5), CSS(3), JavaScript and jQuery.

You’re here in The Netherlands or close to, or are willing to move here.

Viewbook is a small (but fast growing) company with 12 people and is located in the Netherlands. We are very passionate about what we do and we grow quickly, so it matters a lot what every Viewbook team member does. We get direct feedback from our users on what we do so you will the results of what you do immediately.

If you’re interested, we’d love to hear from you, just send and email to rien@viewbook.com.

Viewbook is hiring: front-end developer (Javascript)

By Rien | September 27th, 2011 | No Comments

This is a Dutch vacancy. If you don’t speak Dutch, see English post below.

Met Viewbook kunnen gebruikers wereldwijd portfolio websites en presentaties maken voor het web en mobile. Wij zoeken een front-end developer die ons compacte development team komt versterken voor 3 tot 5 dagen per week.

Met de web-based Viewbook editor kunnen gebruikers makkelijk zelf portfolio websites creeëren op een geheel visuele manier (drag & drop) en een desktop achtige ervaring. Gebruikers kunnen lay-outs aanpassen, modules plaatsen en pagina’s stylen.

De volgende versie (Viewbook V3) van deze tool is volop in ontwikkeling en het is de bedoeling dat je gemotiveerd bent om in ons nieuwe systeem te duiken en nieuwe pagina onderdelen en modules te gaan ontwikkelen. Dit betekent dat je veel gebruik gaat maken van jQuery, backbone.js en voor een deel XSLT om HTML te genereren. Maar hiernaast ontwikkel je ook graag user interfaces samen met een kritisch creatief team en kan je jouw werk goed cross browser debuggen. Aangezien het gaat om een creatie tool is enthousiasme voor onze brede creatieve doelgroep (fotografen en designers) een pre en verwachten we dat je affiniteit hebt met interactieve web-based applicaties (AJAX).

Expertise
Junior/medior met ruime ervaring en kennis van:

* Javascript en jQuery ontwikkeling (inclusief jQuery UI en plugins)
* HTML(5), DOM en CSS(3)
* Interactieve web applicaties (o.a. met AJAX, JSON en XML)
* Kennis van XSLT (of je bent gemotiveerd om het te leren)
* En natuurlijk moet je jou werk goed cross browser kunnen debuggen

Viewbook is een creatieve omgeving in het hart van Rotterdam. Met een klein team (10 man) wordt er hard gewerkt aan het maken van mooie applicaties en interfaces, waar je ook direct feedback op krijgt vanuit de gebruikers. Elk jaar verdubbelt onze wereldwijde gebruikersgroep wat betekent dat we constant bezig zijn met nieuwe dingen ontwikkelen en het verbeteren van ons bestaande systeem. Het is dus heel dynamisch werk met een klein team waarin je resultaat ziet van wat je doet.

Als je interesse hebt stuur dan een email aan bob@viewbook.com.

English

At Viewbook.com users create portfolio websites to present their work to the world. We’re looking for a new person to join our development team. This can both be a freelance or employed position (3 to 5 days) and you’re located in The Netherlands.

With the Viewbook portfolio website editor our users are able to manager their work and create portfolio websites with a desktop like experience. In the next version of Viewbook (Viewbook V3) the website design editor will become much more interactive, giving the user options to edit layouts and add many modules.

Viewbook V3 will be built using jQuery, jQuery UI, Backbone.js, XSLT, and the application talks with RESTful Ruby on Rails webservices. It would be great if all of this sounds more or less familiar to you. We put a lot of effort into making our apps simple and beautiful, so you must have a desire to create perfect things.

We’re looking for someone who is passionate about creating highly interactive Javascript applications and has the following experience, or is eager to learn and learns quickly.

* Deep experience with JavaScript & jQuery
* Deep experience with HTML(5) and CSS(3) and the DOM
* Familiarity with RESTful webservices XML and JSON technologies
* Experience with MVC and libraries such as Backbone.js
* Previous experience developing interactive GUIs, using HTML, JavaScript, CSS, DOM
* Solid understanding of cross browser and cross platform limitations and solutions

Viewbook is a small company (10 people) located in the Netherlands. We are very passionate about what we do and we grow quickly, so it matters a lot what every Viewbook team member does. We get direct feedback from our users on what we do so you will the results of what you do immediately.

If you’re interested send and email to bob@viewbook.com.

The one book you have to read when starting a startup

By Rien | May 26th, 2011 | 1 Comment

It was somewhere in the middle of 2010 and I was preparing a keynote for our two private investors. We’ve lent a small amount of money, and it was time again to tell them about where we were with our company…. but I felt I did not have a clear idea. We were performing good, but what is good? I had a lot of questions that somehow needed an answer: At what ‘stage’ is our company? How can we make it more successful? Do we need more money for promotion? Do we need new investors? What do we have to do next?

A strange titled book gave the answer. ‘The Four Steps to the Ephiphany‘, self-published by Steven Gary Blank. The book gave us a ‘model’ that explained at what ‘stage’ we were and what was to be expected as ‘next steps’ in the future. It pretty well answered all of my questions above. Wow! Yeah. Really it felt like a revelation.

What the book basically does is tear down the idea of the ‘overnight success‘ and instead present a process of ‘discovery and validation’ before even going further with your idea. This is what we used to think about, when executing an idea. First you ‘define the concept’ then ‘develop the product’, ‘alpha and beta test it’ and finally the ‘big launch’, Bang! How sad this ‘big launch’ almost never brings the succes you thought it would bring. But more important, what happens when you’ve launched?

Steven Gary brings us a new model. It’s very simple:

1. Discover your customers
Finding out who the customers for your product are and whether the problem you believe are solving is important to them.

2. Validate if the customer really wants your product, pays for it!
Do you have a proven and repeatable sales process that has been field-tested by succesfully selling the product to early customers?

3. If so start activities that create more customers
If you can definitely say a loud ‘yes’ to the steps above you can start spending money on promotional activities.

4. Then grow your company
Time to structure your company when it grows.

Well that’s very simple, almost obvious. Yes it is, but it’s oh so tempting to think your product will be ‘the next big hit’, without discovering thourougly what your customers want and what you are really solving for them. We were somewhere between step 1 and 2 at that moment. As with most products you do not have one clear target group, but a lot of segmented groups. It’s a challenge to find the right focus for your product.

Steve’s ideas gave us a ‘framework’ to think better about where we were as a company, when to invest in what. He gives many more insights, like what type of market you think you’re in and what this means for your marketing and positioning. In essence it’s about ‘learning and iterating versus linear execution’. This stuff wil definitely help you when you’re starting your own startup or when you just tarted.

Configuration to the power of XSLT

By Bob | March 28th, 2011 | No Comments

At Viewbook we are using XSLT (Extensible Stylesheet Language Transformations) to build a new generation of powerful website building tools within the Viewbook framework (more on that later). I have been working with XSLT for about 4 years now, so it came naturally to me to offer it as the preferred approach to get the system working. But using XSLT isn’t exactly a mainstream approach for web development (yet), so why did we choose XSLT for the job?

What does XSLT solve?
Thinking about how we would ideally set up the new range of tools, it quickly came down to one rather fundamental question. How can we easily combine a multitude of configuration and data sources into all the needed output types? And more importantly, how could we keep the overall system agile and scalable?

The configuration method of choice came down to XML (doesn’t it almost always). It’s easy to produce, great for rapid prototyping (just edit a static file) and can be easily generated by any back-end system. XML configuration does however has it downsides when you want to use it to generate the output. It’s pretty verbose and parsing can be a pain and can require a lot of code, and this is exactly where XSLT comes in.

What is XSLT?
So what is XSLT? In short it is a great way to loop through each and every bit of an XML source, and transform that bit into something else on the fly and only if needed. You can use it to generate any type of output from a single XML source: Text, XML, HTML, CSS, Javascript, SVG, a PDF or anything in between. In essence this means with XSLT you can produce any type of content and truly abstract your data and configuration from your output and transforming logic.

What does XSLT look like?
Letís do a concrete example. Suppose you want to render various pieces of HTML into one or more pages, where each bit has the same basic structure but different content and styling. And as a bonus letís keep the database as a flat as possible.

The XML configuration could look something like this:

<data>
<item>
<structure>
<section>
<header>
<h1 id="h-h1"/>
<p id="h-p"/>
</header>
<p id="s-p"/>
</section>
</structure>
<options>
<item type="content" id="h-h1">
Custom Title
</item>
<item type="content" id="h-p">
Lorem ipsum dolor sit amet, consecteturadipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua.
</item>
<item type="content" id="s-p">
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem
aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
</item>
<item type="style" id="h-h1">
font-size:24px
</item>
<item type="style" id="h-p">
font-size:14px
</item>
<item type="style" id="s-p">
font-size:12px
</item>
</options>
</item>
</data>

And with XSLT like this:

<!– load in your data –>
<xsl:variable name="data" select="document('http://url-to-your-data.xml')" />
<xsl:template match="/">
<!– loop through the basic structure –>
<xsl:apply-templates select="$data/data/item/structure/*" mode="html" />
<style>
<xsl:comment>
<!– sum up all css styles –>
<xsl:apply-templates select="$data/data/item/options/item[@type= 'style']" mode="style" />
</xsl:comment>
</style>
</xsl:template>
<!–
template copy using the "The Ninja Technique"
http://symphony-cms.com/learn/articles/view/html-ninja-technique/
–>
<xsl:template match="*" mode="html">
<!– store the content reference id –>
<xsl:variable name="el-id" select="@id" />
<xsl:element name="{name()}">
<xsl:choose>
<!–
This matches the elements 'id' from the config structure
with any possible 'id' in the config options and pasts in the content
–>
<xsl:when test="$el-id and $data/data/item/options/item[@type = 'content' and @id = $el-id]">
<xsl:apply-templates select="@*" mode="html" />
<xsl:value-of select="$data/data/item/options/item[@id = $el-id]" />
</xsl:when>
<xsl:otherwise>
<!– otherwise just copy the config structure –>
<xsl:apply-templates select="* | @* | text()" mode="html" />
</xsl:otherwise>
</xsl:choose>
</xsl:element>
</xsl:template>
<xsl:template match="@*" mode="html">
<xsl:attribute name="{name()}">
<xsl:value-of select="." />
</xsl:attribute>
</xsl:template>
<!– Template copy –>
<!– css style generation –>
<xsl:template match="item" mode="style">
<xsl:text>#</xsl:text>
<xsl:value-of select="@id" />
<xsl:text>{</xsl:text>
<xsl:value-of select="." />
<xsl:text>;}</xsl:text>
</xsl:template>
<!– css style generation –>

You would produce:

<section>
<header>
<h1 id="h-h1">
Custom Title
</h1>
<p id="h-p">
Lorem ipsum dolor sit amet, consecteturadipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
</p>
</header>
<p id="s-p">
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa
quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
</p>
</section>
<style>
<!–#h-h1{font-size:24px;}#h-p{font-size:14px;}#s-p{font-size:12px;}–>
</style>

Obviously this is a pretty simple example witch could be improved upon, but thatís simply a case of making more specific template matches and adjust your XSLT as needed.

No disadvantages?
XSLT does has it’s downsides of course, like most technologies do. First of all mastering XSLT can be a steep learning curve and requires a different ‘mindset’ to get started. XSLT is a templating language, you loop, match and transform. Whereas other transform languages often use a loaded DOM and ‘paste’ new content in afterwards. The latter generally would be a more familiar approach for most developers.

Secondly XSLT isn’t really known for it’s mathematical prowess, it’s a XML transformation language after all. Although XSLT 2.0 does solve this for a great deal, that version isn’t really widespread yet. External libraries like EXSLT do solve much of the headaches in the mean time though. And finally working with very large XML documents (as in thousands of lines of XML) can pose performance issues if not careful, although I myself never run into this before.

Conclusion
So XSLT is a great way to produce any type of content from your database and really abstracts configuration from output. Besides this XSLT is a platform neutral way of rendering the output. So that means there is always a XSLT processor you can use in the language you’re most familiar with. And of course XSLT is just about transforming XML, nothing more and nothing less. So if you’re working with XML, XSLT is the way to go.

Issue Trackers: Jira versus Lighthouse and Pivotal Tracker

By Rien | March 20th, 2011 | 5 Comments

We’ve been using Lighthouse here at Viewbook for a long time and switched to Jira in combination with Greenhopper recently. Mainly to get more into Scrum. When I started looking into issue trackers my basic wishlist was:
* Filter and sort on tickets with all sorts of criteria, mainly on assignee and status.
* Quick overview of tickets in different releases and projects and their status.
* Basic support of Scrum.
* Simple workflow.
* Easy to comment on tickets; large text fields and updates via email.
* Easy to use and to understand for team members.

Lighthouse
We’ve hosted an application at EngineYard in the past, and with it came free use of Lighthouse. A simple and easy to use issue tracker. No bells and whistles. It functioned great for us, the clean interface and simplicity and email notification made it a practical tool. However there are a couple of drawbacks that made me look for an alternative. Filtering tickets, by assignee, status and priority is not intuitive and it’s kind of hard to add new filters. Also getting release or project overviews is not that great, thus making it hard to support a methodology like Scrum.

Jira and Greenhopper
In my search for Scrum supported tools I came across Greenhopper that integrates seamlessly with Jira. With Atlassin’s ‘$10 Starter‘ offer it was a no brainer to check out both packages. Installation did not go very smoothly. The Java SDK simply did not finish to install on an Ubuntu system with 512MB memory. Upgraded the machine to 1024MB memory and all went fine. Initial configuration is a bit cumbersome and is done by adding and removing a couple of lines in XML files. Mainly configuring database properties (I’ve used Mysql as database). Then discovering all the options the software has to offer begins. And with Jira, thats’s a lot.

The flexibility and default workflow of Jira immediately fell in place. It simply feels more professional. The workflow is both simple and logical: Tickets have the following states: ‘new’, ‘open’, ‘resolved’ or ‘closed’. Closing is done by the project owner or tester when all works fine, or the ticket can be reopened when there’s still work to do. Of course you can change this but it works fine for us. We use subtasks to group issues together during testing that belong to a certain part of the software. When adding Greenhopper to Jira you get another option called ‘Agile’ which gives you scrum like overviews into your projects or releases. With a drag & drop interface that makes it very easy to move tickets into a next status.

Pivotal Tracker
We’ve never used Pivotal Tracker in production. But I’ve logged in many times to check and learn more about it. Purely as issue tracker (or bug tracker) Pivotal is not the most ideal solution to me. But as project tool, especially when doing Agile / Scrum, it looks great. It automatically prioritizes tickets depending on velocity and stuff that needs to be done, which is a great feature, but also can stand in the way for simple issue tracking.

Conclusion
So what tool to use for what job? When you’re a startup looking for a simple easy to use issue tracker, or you’re doing an Open Source project, Lighthouse is the tool to go for. If you need more flexibility, solid workflow and better overview, the industry leader Jira in combination with Greenhopper is your choice (and you get both for just $20!!! when you’re with a team of 10 or less). And finally if you’re heavily into agile development and focus on (different) projects a lot, Pivotal Tracker is what you should look into.

CSS3 Media Queries for dynamically resizing elements on different screen sizes

By Rien | March 12th, 2011 | 3 Comments

With the new website for Viewbook we’ve started to implement HTML5 and CSS3 features, including the CSS3 media query. This simple little magical line of CSS turned out be very powerful for us:

/* 1024 and smaller screens */
@media screen and (max-width:1024px){
#container #content article{
max-width:980px;
}
#tour.upload-and-organize {
background:url('/tour/upload-panel-1024.png');
}
}
/* 1680 and larger screens */
@media screen and (min-width:1680px){
#container #content article{
max-width:1500px;
}
#tour.upload-and-organize {
background:url('/tour/upload-panel-1680.png');
}
}

We wanted the website to display perfectly on many screen-sizes, from extremely small like the iPhone to extremely large like the 27″ iMacs. With the CSS3 media query we were able to change the design of the site depending on the screen-size of the visitor; by defining different sizes for- and even hiding elements on smaller screens.

In the tour section you can see this in action. Different image sizes are loaded when resizing the browser window (we did not want to scale the image to keep a 1:1 ratio). There’s a default fallback in ‘normal CSS’ for browsers that do not support the media query. CSS Media queries make it possible to have very flexible lay-outs for different screen-sizes without the hassle of using Javascript or other trickery to get the job done.

Mobile Safari: Image Resource Limit

By Rien | February 22nd, 2011 | No Comments

Thijs van der Vossen from Fingertips, developer of our new galleries for iPhone, iPad and other mobile devices, wrote a great post about a workaround for the limit of image data that can be loaded on a single HTML page in Mobile Safari. This limit is somewhere in between 8 and 10 mb.

When loading a gallery with 30 images of 500KB, Mobile Safari simply refuses to display the last 10 images. A problem that already occurred in a previous version of our mobile galleries.

To guarantee properly loading of images in larger galleries we are optimizing our images for Mobile use. Special more compressed images are generated, to solve the resource limit in Mobile Safari, but also to make loading on mobile networks much faster.

Check his post here: How to work around the Mobile Safari image resource limit

Mobile Safari: Offline Application Cache Limit

By Rien | February 22nd, 2011 | 4 Comments

Recently we’ve launched our new mobile galleries. I’ve experimented in an earlier stage with Mobile Safari’s Offline Application cache with a very simple idea: to give the user the option to locally store an image gallery for offline use. Great in combination with the ‘Add to Homescreen’ functionality that the iPhone an iPad provides.

Implementation was simple using the Apple Developer docs and the great tutorials here, all worked great. Except when downloading more than 5MB of data, the process simply hangs. Damn, that’s not a lot. Apple’s documentation does not say anything about a caching limit. Posted a question about a caching limit on StackOverflow, but found no definitive answer on the cache limit of Mobile Safari’s Offline Application cache.

After sending an e-mail to Apple Developer support I did not get a definite answer on the 5mb limit, but “that there is no supported way to achieve the desired functionality given the currently shipping system configurations” .

My e-mail:

Name: Rien Swagerman
E-mail: rien@viewbook.com
Company: viewbook.com
iPhone Developer Program Team ID: none
Follow-Up ID (if referring or responding to an open issue): none

DESCRIPTION OF PROBLEM
When using the manifest file for Safari Offline Application Cache there seems to be a limit of 5mb to cache (iPad and iPhone). Is this correct?

We want to provide offline image galleries to our users (on the iPad and iPhone), synced with their viewbook.com galleries, but this needs more data storage than 5mb. Is this possible (in the near future)?

For us it is a strategic choice to either use Safari, or if not possible create a native app for the iPad and iPhone.

STEPS TO REPRODUCE
Use manifest file that loads more than 5mb of files.

NOTES AND ATTACHMENTS
None.

———————————

Thanks,
Rien swagerman.

Apple’s response:

Hello Rien,

Thank you for contacting Apple Developer Technical Support (DTS). Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations.

If you would like for Apple to consider adding support for such features in the future, please submit an enhancement request via the Bug Reporter tool at <http://bugreport.apple.com>.

Thank you for taking the time to file this report. We truly appreciate your help in discovering and isolating issues.

Best Regards,

Vanaja Pasumarthi
Apple Developer Support
Worldwide Developer Relations