FERDY CHRISTANT - AUG 24, 2015 (07:32:24 PM)
If you've read post 1 and post 2 regarding Calumma, and the long time between those posts, you may assume it is a project that isn't going anywhere, or at least has little progress. You may also still struggle to understand why you should care about it.
Luckily, progress is far from slow, my writing is. I'm at least 10 posts behind in documenting its status. The other good news is that it contains some very powerful things that likely interest you if you're a web developer. In this third post, I hope to clear things up by giving a rough outline of things to come.
Defining Calumma again
In the previous post I've discussed at length why I'm not using any of the off-the-shelf frameworks out there. I've finally found the right word for what most of Calumma is about: it is a design system. Not a framework.
Technically, it is a styleguide on steroids. It consists of CSS and a little JS. Styleguides are opinionated, so why should you care about this one? I think Calumma is interesting because it takes a fresh and deep look at various web design topics and comes up with a robust approach to design very quickly and flexibly. In fact, if I would show you now the current status of this design system, you'd ask me to give you the code, or so I hope.
But as said, I'm far behind in writing about it, so let us start with how it is organized, and what thinks are to come in follow-up posts.
Choice of CSS Preprocessor
As explained in post 1, my choice of CSS preprocessor is SASS/SCSS in combination with Compass. Primarly because I've never looked back after first using it. In this project, I'm using the following features of SASS:
- Modules (imports)
In other words, pretty much every SASS feature. SASS/SCSS is a fundamental tool in creating the powerful and flexible design system that I am aiming for.
Choice of CSS architecture
A few words on CSS architecture. There's different schools of thought here. There's the purist, semantic school that for example would code a product registration button like this:
<a href="" class="button_registration">Register</a>
As you can see, the class is semantically named. Next, all styles specific to that button instance would be in the CSS. There's a clean separation between markup and style.
The opposing school of though is a more declarative approach:
<a href="" class="button button_primary button_submit">Register</a>
This is a BEM-like approach, part of a family of similar approaches like OOCSS and SMACSS. With this approach, we stack class names on the element from general to specific. Some of those class names may actually dictate the way the button looks.
Between these two "extremes", there's various shades of grey. Originally, I'm from the purists school, but increasingly I'm understanding the power of the BEM-like approach. The reason for that is pretty simple. The main gripe purists have with the BEM-like approach is that it is not semantic.
That is only partly true. The class attribute of an element has no semantic value to end-users, search engines, or screen readers. None at all. It only has some semantic value to developers. In other words, it's a question of maintainability, not semantics. If you can use a BEM-like approach that is semantic and therefore maintainable by developers, you're good to go.
Calumma uses a BEM-like approach due to the great power it brings in declaratively designing things. This point will become more clear over time.
Allright, with that behind us, let's finally get into the actual SCSS. In this post I will only list the modules and how I organize them. The basic premise is simple: in my src/scss folder, I have a single main.scss. From that file, I import the partials that are in the same dir. Partials are simply SCSS files that start with an underscore in their filename. This way, we can organize our project into modules.
Here's my current main.scss. It is subject to change as the project progresses, but it gives you an idea:
Below is a short description of each:
The order of imports matters, therefore if any module is to use Compass functions, it's best to import Compass the the very top. I used to use Compass as a way to avoid vendor prefixes, but now that I'm using auto-prefixing in my build process, I barely use Compass anymore. The only thing I use it for is for its color helper functions.
This one is very interesting. Schooled designers often use well-documented ratios (like to golden ratio) to design things in attractice proportions. This module allows you to generate such a scale, which you can then use as units in the rest of the project, from setting a font size to setting margins, anything you like.
Still needed, a baseline to set some styles to robust defaults so that we avoid nasty surprises in different browsers.
A very important module. Anything that can be controlled with a variable in the project, will be controlled from here, thus it kind of is a dashboard. This is where we define breakpoints, color schemes and much more. Ultimately, the flexibility and reusability of the project starts here.
This is where I put any helper functions that I need across the project. So far, there's only 2 mixins in it, so I'm a light user of mixins.
One of the most powerful components of this design system. I've taken a great grid, converted it to SASS and made it even more powerful. The things it can do will blow your mind, or so I hope. I will use multiple posts to fully explain it later on.
Layout helpers. Combined with the grid, layout concerns are a thing of the past.
Anything related to typography. Our choice of font, margins, font variations and weight, text modifiers, there's a lot to discuss here.
The famous icon font, also included in this project.
How general thing are styled. With "general" I mean elements that have no class.
Form layouts, input elements, error messages and such.
Tab systems, pills, breadcrumbs, etc.
Anything that is very specific to the pages that I will design will be put here. For example, a user or tag is a very specific component, whilst a tab system is very generic. This is an attempt to separate highly specific things from general things. I have every intention to reuse this design system for other projects, and this keeps things managable.
A very interesting experiment. This concerns a color map definition that is used to generate color and texture classes that you can apply at will to any element, along with various tone and alpha variations.
Layout that is specific to a page or design (or template) will be put here, clearly separating it from general layout helpers.
We'll be experimenting with the new picture element here, and I have lots of exciting things to tell about it.
General helpers for making things round, bordered, transparant, etc.
At the end of main.scss, you can also see a placeholder for vendor.scss (for any plugins I may use) and breakpoint-specific SCSS. Those are not implemented yet.
It is quite arbitrary how one would organize SCSS into modules, and I'll adjust it as I go along. I am guiding this organization with the following principles in mind:
- Components should never have layout. With that I mean they should not have any specific width or margin. Doing so would decrease reusability. Instead, a parent layout container will determine the constraint of the component, and not the component itself. This is an important concept that increases reusability and avoids a lot of duplication and pixel pushing.
- Responsive as a default. I'm trying to code components responsive as a default, ideally in a way that does not lead to an overdosis of media queries.
- Solve a problem only once. As you can see from the modules, I have a lot of general helper modules. Whenever I need to accomplish something new, I first think of it as a general problem, and come up with a general implementation.
- Needs-based. Instead of trying to solve design problem in the world, I'm focusing on real-world needs, an inside-out approach.
- Progressive. In this project, I will not be constrained by shitty old browsers. I will use modern and new ways of solving things that work in most browsers. Only later I will consider fallbacks and polyfills, if at all. We should not limit our creativity by the past, this project looks forward. At least where it can.
FERDY CHRISTANT - AUG 7, 2015 (11:29:26 AM)
I've defined myself a project called Calumma, which has two goals:
- To experiment with new web technology
- To take learnings from those experiments for use in a future version of JungleDragon
I will be documenting my progress here, allowing you to watch over my shoulder. Roughly, the project consists of these steps:
- Setting up an efficient development workflow
- Implementing a front-end architecture
- Designing advanced pages based on the previous
Along each and every step, a main goal is to experiment and learn. The journey is just as important as the result. In my first post, I've explained my current development workflow, which is simple yet powerful.
The bulk of the work in this project though is in the front-end architecture. In this 2nd post, I will theorize about this front-end architecture step, what it is, why it is needed, and why I'm creating one from scratch. We need to get this out of the way before we can finally start to code.
What is a front-end architecture and why do we need one?
Web development is increasingly complex, particularly in the front-end. Despite the base technologies like HTML and CSS still being simple in nature, our front-end code lives in the demanding wild:
- It should be semantic and accessible
- It should be maintainable
- It should work on a myriad of devices and scenarios
- It should perform well (speed)
- It should be future-proof
- It should look good and consistent
As such, we need to put some structure into how we apply our base technologies HTML, CSS, JS). We need to make a large series of technical decisions on how we will go about our implementation, some examples:
- How do we do feature detection?
- Will the site be desktop-first, or mobile-first and how will we implement this?
- How will we reuse styles and components?
- What is our typography approach?
- What about layout?
- What is our progressive enhancement strategy?
- Which browsers will we support?
- How will we optimize for performance?
- Which CSS strategy do we use, classic or BEM-like?
The list goes on. There are a lot of decisions to make, and the collective decisions on all these questions is what ultimately defines your front-end architecture.
Front-end architecture vs framework
So far, I've been using the word front-end architecture intentionally to avoid the framework word. There's an important difference to consider.
As a developer, there is a tendency to make your front-end architecture as reusable and powerful as possible, effectively turning your architecture into a framework, a base that can be used for other projects as well. This is a slippery slope, because a front-end architecture that tries to solve all potential problems the world has to offer, will ultimately always lead to a buch of bloat, and not be good at anything.
As I go about this specific front-end architecture, yes, I will have reuse and standardization in mind, but it will be balanced by actual needs. Don't solve a problem you don't actually have. Simply put, a front-end architecture is specific (yet can have reusable parts), whilst a framework is generic. With Calumma, I'm building a front-end architecture, not a framework.
Why not Bootstrap?
On my previous post, somebody asked why I'm doing this at all, why not just use Bootstrap, which likely has > 80% of most front-end needs covered? I replied with a shitty answer, saying I don't like Bootstrap. That's not the truth, well only partly. It is a great question, that deserves a much better answer, so here goes:
Bootstrap is not a bootstrap
The name "bootstrap" suggests it is a minimal foundation from which you go and make specific implementations based on your own needs. That's not what Bootstrap is. Bootstrap is an all-out, invasive framework that dominates your front-end architecture. If you create a web project based on Bootstrap, it will not be a web project that happens to have a Bootstrap foundation, you will have a Bootstrap web project.
That may actually be fine in many scenarios, but it is something to realize. But wait, Bootstrap allows you to customize which parts of the framework you like to use. Yes, it sure does. Have a look at the customization page. The sheer amount of options there only confirms how extensive bootstrap is. Again, that can be a good thing in many scenarios, I'm just establishing the point that Bootstrap is a not a bootstrap.
Bootstrap sites all look the same
Which doesn't mean they look bad, they just all look the same. And that makes sense. Whilst you can customize anything you want in Bootstrap, doing so extensively would defeat the whole point of using Bootstrap at all. Whenever I open a website, I can instantly see whether it uses Bootstrap or not.
Is that bad? Not always. It depends on your design goals and the strategic positioning of the website. Say for example that I'm asked to develop a website for a business that sells coffee mugs. Their true business is making coffee mugs, their website is simply a sales channel to sell them. As such, the website is a means to an end.
In a scenario like that, I would totally consider using Bootstrap. It would allow me to crank out a good-looking website very quickly, and all parties would be happy. Well done.
In my situation, however, the web experience is not a means to an end, it is the end. The web experience itself IS the product. And for that reason, it deserves to be specialized. Specialized technically, to avoid bloat, but also specialized design-wise. For this reason, Bootstrap is not always the best choice, even if it boosts your productivity.
Bootstrap doesn't learn me anything
As stated previously, one of the main goals of project Calumma is to experiment with web technology as a way of learning new things, which will then be used to help define the future of JungleDragon. Bootstrap does not align with this goal, it's as simple as that. It has already made all the choices for me.
There's a fair amount of criticism on some of Bootstrap's specific technical choices. Examples are how it deals with responsive design, the non-semantic markup and bloat, and more. I support and agree with most of this criticism, but don't want to restart that ancient flame war. I think it is enough to say that Bootstrap has its limitations and is not perfect.
To me though, this isn't even about Bootstrap making wrong decisions, it is about Bootstrap making the decision at all. It simply makes far too many decisions for the purpose of my project, which has different goals.
Scope of the front-end architecture
I hope that explained why I'm not using Bootstrap. A great choice for many web projects, but not for this one. Anyway, with that out of the way, here's an explanation of what I would consider the scope of the Calumma front-end architecture.
Almost all of it will be about presentation, which includes:
- General styles
- Forms and buttons
- Layout (grid and page layout)
All of this will be intermixed with progressive enhancement, performance, responsive behavior and more. This sounds like the typical styleguide, and that is exactly what it is. It will be a styleguide on steroids though, making some interesting new choices. It's not as boring as you imagine. The next few posts will discuss it in detail, explaning both design choices and technical choices.
As part of the framework, there will also be an organizational setup for JS, but it will not play a major role in my posts for a while, all in good time.
The goal of the front-end architecture I'm building (besides learning new things) is being able to design quickly, flexibly and robustly, based on a common design language. I know how vague that sounds, but I will soon demonstrate you that it is not a pipe dream. I will actually show how I create a brand-new, complicated component, without writing a single line of CSS, simply by making use of the powerful front-end architecture.
The next post will discuss the implementation of the front-end architecture, starting with how we organize it. I promise you, this will get ever more interesting over time.
FERDY CHRISTANT - JUL 30, 2015 (10:28:07 PM)
I just upgraded to Windows 10, coming from Windows 8.1. Kind of a bold move, since I just spend 3 days doing a reinstall, migrating to an SSD, and getting all my programs and settings back in order. Anyways, it worked, otherwise you would not be reading this.
In this post I want to share some first impressions. This is not a review, just some observations after having worked with Windows 10 for less than an hour. The first hour is crucial, as it literally is the first impression one gets of a new operating system. Note that my perspective is that of a desktop user, using a mouse and keyboard on 2 large screens.
On Windows 8.1, I've been seeing the little Windows logo icon reminding me of the coming W10 upgrade for several weeks. After reserving my instance, today I clicked it, and it showed me it was ready for the install. Somehow it did not actually notify me, but that's ok.
I selected to "upgrade now", which kicked of the installation. In total, the PC rebooted 3 times. The 2nd reboot it took a very long time before anything came up, which worried me, but eventually the process continued. After the third reboot, I got some welcome messages, in dutch, which is weird, because it means it has forgotten my english preference. The rest of the OS was still in english, luckily.
Next, I was asked to indicate a few configuration preferences. Earlier this week I've read about the privacy concerns of Windows 10, and therefore was paying specific attention to this step. What followed is a very sleezy step by Microsoft. Here's the deal: by default, Microsoft will capture an insane amount of data from you, supposedly to "improve your experience". This includes application usage, your browser history, your typing behavior, the list goes on. You can disable all these things, but only if you find the tiny text-like link in the configuration screen that takes you to that settings page. The default is clearly to steer you towards the zero privacy model.
Before exploring anything of Windows 10 itself, I first wanted to see whether any damage was inflicted. The displays seemed to work fine, on their native resolution. No Nvidia driver issues, which caused a lot of issues for users earlier this week. Sound was working as well, all my taskbar icons are there still. Also important, I wasn't asked for a product key, meaning my genuine copy was detected succesfully. Weirdly, my wallpaper was wiped, but that was easy to restore.
The only other issue I faced was a fatal error on a VM I started in VMWare, which kind of panicked me. Luckily, rebooting once more solved that issue automatically.
Overall, I consider the upgrade process itself to be smooth. It could have been worse. The privacy attack though is inexcusable, and frankly disgusts me.
I never had a big problem with the start menu being removed in Windows 8, since I launch all my programs from the task bar. Still, it is back, which I consider an improvement. In Windows 8, I had to exactly position my mouse in the far top right corner, and do it very precisely, so that I do not enter into my second screen accidentally. That was a ridiculous user interaction to do for a desktop user, so this is much better.
The new start menu works OK, and now has this series of Modern Apps tiles attached to them. I clicked the Twitter app, yet nothing happened. The Weather app did work, and shows a very important change in Windows 10: running Modern Apps in the desktop. I'll get back to what that means in a minute.
Another new desktop feature, available for decades in Linux/Unix, is multiple desktops. A welcome addition, but too hard to discover for a casual user. You initiate it from "Task view", which has an icon that looks like multiple windows, not multiple desktops. From this screen, the far bottom right has a link "Add desktop". I actually did not see it due to the size of my screen, and had to Google how it works. It works, but in my opinion it is poorly implemented and hard to discover.
Windows 10 ships with a new browser called "Edge". And that makes me happy. The reason being, Edge is advertised as the good old blue internet explorer icon. This means that all those users reluctant to let go of what they see as "the internet", will now end up in Edge, instead of old IE. That's a good thing for web standards, and for people who build websites, like me.
Edge itself is lean and mean, fast and works well based on a quick check. The minimalism is a bit extreme though, and will likely confuse casual users. Furthermore, it lacks extensions and has poor inspection tools, but hey, it's a young browser, all of that may improve over time.
Control panel (settings)
In Windows 10, Microsoft has moved more options from the classic control panel towards the Modern UI settings app. Unfortunately, that makes it all even more confusing.
As an example, I wanted to check my resolution by right-clicking my desktop, something that I have been doing for close to 20 years. Now this takes me to the settings app, and there's no resolution. Only after finding the advanced settings link, which doesn't even look like a link, I can access the resolution. Basically, the settings are dumbed down, geared towards common usage, not power usage. If you're used to particular places and shortcuts to quickly adjust settings, you may now see them moved.
You can still go back to the classic control panel, and eventually find it, it's just a confusing experience overall.
Windows 10 overall
Time for some overall impressions. There's two critical notes that I have: Windows 10 is ugly and inconsistent.
First, the ugly part. It's very subjective, but I don't like the over the top minimalism. I have nothing against the recent trend of simple and flat UIs, but Microsoft has pushed it over the edge, where it starts to hurt actual usability. For example, Edge is all white until you click on this magical white area to reveal an address bar, which has some slight contrast to it. Some users may not even know how to go to a website at all, thinking their number one feature has just vanished. Another example is the new settings app, which is all black and white and some blue, and uses screen real estate very poorly. A similar thing is true in Office 2013, where you cannot even see where a menu ends and a document begins, because it all is just so flat and white.
I'm not a fan, like I'm also still not a fan of the crazy bright tiles, it's the first thing I removed from the new start menu.
But all of that is a matter of taste. Perhaps you do like it. Let us assume for a moment that we do. Windows 10 then still is ugly due to the incredible inconsistency that is all over the place. Allow me to explain.
Because you can now run Modern apps in the desktop, they're going to sit side by side your Win32 apps. They look incredibly different. This was not the case for Windows 8, where many desktop users simply booted to the desktop and never saw much of Modern UI. Now it is in your face, mixed with the traditional look. And Microsoft is actively increasing that exposure by promoting store apps.
Given that Win32 apps will definitely be used for another decade or more, it means this horrible inconsistency will be with us for a very long time.
But that's not the end of it. The inconsistency is weaved throughout the system. You see it in icons, different styles, menus, and the system switching you between classic and modern screens as you try to get things done. With Windows 8, many reviewers concluded that it is a weird combination of two operating systems. Some reviewers of Windows 10 now conclude that Microsoft has taken giant steps to close that gap, and make it feel like one.
I couldn't disagree more. It feels even more like a Frankenstein OS now, because for desktop users they will have more mixed UI experiences, not less. I very well understand that what Microsoft is trying to do is a giant move, but I'm quite dissapointed with the limited progress over the years. If you have years to improve the world's most used and most important operating system, with billions in the bank, and then end up with this...there's reason to worry. A lot.
To me personally, none of this matters. I found Windows 8 weird and inconsistent, and then moved on. I pin my programs to the task bar, and get going. It works. The same is true for Windows 10, I can just keep doing what I was doing already.
In light of the bigger picture though, those billion Windows users, I think Microsoft is in a risky place. It will be a very long transition (10+ years) towards a fullly consistent "modern" experience, and then again, it's even questionable whether people like the end-result. It's subjective and anecdotical evidence, but I know few people who digg the look and feel. Furthermore, how will Microsoft get the producers of the largest software catalog on the planet (W32) to move to this new model? Will desktop users actually start using and paying for these apps?
Time will tell, but they are very big question marks. To end this first impression on a positive note:
- The installation is smooth and mostly trouble-free
- Edge as the new default browser is a great development
- The start menu being back is a good improvement (or restoration of what once was)
- Multiple desktops is useful, although hard to discover
That's it for now, what are your first impressions?
Update: An additional problem found is that the upgrade wiped my install of Ruby and all gems. NPM did survive the upgrade.
FERDY CHRISTANT - JUL 27, 2015 (09:45:23 PM)
I have a war story to tell, a failure on my behalf, yet one mistake I imagine many people potentially make. Therefore this blog post is a warning, if you're making use of VMWare snapshots.
Snapshots, how I thought they work
A while back, I replaced my physical development server with a virtual one. I used VMware to mount to a Debian install ISO and started to build up a full server from there. I paid for a copy of VMWare Workstation, since it has some features I needed, primarily support for snapshots.
I figured to use snapshots for two reasons:
- To be able to do a rollback. Before doing a risky configuration change, I'd make a snapshot. Next, I proceeded. If I screw up something, I go back to the snapshot.
- To generalize my VM. The further you configure a server, the more specific it becomes. By creating snapshots at key moments, I could spin off a new VM from a very generic state in the history.
With this model in mind, over time I collected about 25 snapshots. On disk I could see that each took about 4GB in size, the same size as the main VM disk file. No problem, I was working on a 2TB disk, with room to spare.
The word "Snapshot" suggests to me you make a copy in time of something. The copy is independent. Seeing the snapshot files take up the same amount of space as the main VM further strengthens this belief.
Snapshots, how they actually work
All of the above assumptions and beliefs are entirely wrong:
- Snapshots are NOT independent copies. They are delta files. You cannot and should not use them for backup purposes
- Snapshots are linked to each other. If you delete one from disk, outside of the snapshot manager, you destroy the integrity of all your snapshots
- Snapshots should NOT be used for a period longer than 24-72 hours
- Snapshots, the amount of them, directly decreases the performance of the last state of your VM, since the last state is the combination of the main disk and the snapshots
- Deleting a snapshot in your history of snapshots (correctly, using the snapshot manager) means a very heavy reconsolidation action that can take hours, if not longer.
- Should you ever get a disk corruption issue in your VM (a virtual corruption, that is), it may corrupt your entire history of snapshots.
I've learned the above the hard way. Yes, I admit ignorance. But I also blame VMWare. The only conclusion I can make based on the above, is that VMWare snapshots are NOT snapshots. Snapshots, by defintion, are independent captures in time of something. VMWare snapshots do not meet that basic expectation. Let's use the literal word "snapshot" in an analogy:
You take a snapshot (photo) of yourself every day for a year. You end up with 365 photos, or snapshots, that captured you in a particular moment in time. Would you now expect the following:
- If you lose one of the snapshots, all are ruined
- If you scratch a single photo, all are scratched
- Taking a new snapshot takes exponentially longer each day
How did I find out this ugly truth? Here's the link, the dark side of VMWare snapshots.
FERDY CHRISTANT - JUL 27, 2015 (08:52:41 PM)
Although the whole world has gone mobile, when at home I tend to prefer work and play in my home office, which consists of a powerful desktop (Alienware Aurora R4) and 2 large 27" screens at 2560 x 1440. I've been enjoying this setup since 2012 on a daily basic, trouble free.
However, the system still has a conventional HDD, and upgrading to a SDD drive for long has been on my list of things to do. For about 2 years actually :) Anyway, as I increasingly found the disk to be the slowest part of the system, I finally had an incentive to do something about it. So last weekend I took the plunge, this post simply lists some of my experiences.
I wanted to feel the SSD performance upgrade across the board, so I went for a no-compromise solution: a 1TB SSD, the Samsung 850 EVO. Yes, having your OS on the SSD in itself is a vast improvement, however, I do very heavy photo editing (36MP photos) and work a lot with virtual machines. If those 2 tasks would still be done on a normal HDD, the upgrade would be far less of an upgrade overall. That said, since I would still have my conventional 2TB HDD, I will reconfigure that to be secondary drive, for even more storage.
Finally, there's an additional goal. My Aurora R4 shipped with a built-in copy of Windows 8. However, it is not shipped as a disk, nor is there a product key sticker anywhere. It is part of the BIOS or part of the recovery partition, I'm still not sure which.
Anyway, I want to keep that genuine Windows copy as part of the upgrade. It will help me transition to Windows 10 in a smoother way. Furthermore, the particular install of Windows 8 comes with Alienware utilities and drivers which are convenient to keep.
I've pondered over how to approach this upgrade. At first, I figured to just clone my entire current HDD. This way, the upgrade would be seamless. However, as my current Windows install is over 2 years old and goes well over 1TB, I ultimately decided to do a clean install (after first backing up everything onto my NAS).
A clean install of the factory setup, that is. I burned restore discs from Alien Autopsy, as the option to restore from the restore partition failed, I'm still not sure why. Using the discs worked. However, I then had several hours of Windows updates to install, both from Windows 8 and Windows 8.1.
With everything backed up and a clean, genuine install on the HDD, I figured the transition would be simple. Here's what I had in mind:
- Physically install SSD (in slot 2, slot 1 being used by the normal HDD)
- Check in BIOS if SSD is recognized, boot to Windows
- In Windows, clone the HDD to the SSD (using Samsung's data migration software)
- Reboot, and in the BIOS change the boot order to boot to the SSD
- Enjoy new SSD as if nothing happened
- Format normal HDD and use as 2nd drive
Simple enough. Except for the fact that every single step in that plan failed, and then some more. I spent close to a day chasing solutions to problems only to arrive at even more problems. It was such a large series of failures that I cannot even retrace all steps, but here's a few things I experienced:
- The SSD not being recognized in the BIOS. A BIOS update to V11 did not fix this either
- The Samsung software not recognizing the SSD at all, yet suddenly detecting it after a reboot
- The BIOS not recognizing my normal drive anymore either
- The clone method cloning to a non-C drive
- My entire system crashing when using AHCI mode (which is recommended for SSDs)
- The system booting to Windows with the SSD as secondary drive (which is not what I want)
- The system booting to Windows with the SSD as primary drive, yet with the wrong drive letter, screwing up the entire Windows install
The list is far longer than that, but I'll stop here. It did not go smooth, suffice to say.
It was very hard to find the problem, since everybody has a slightly different setup, goals and situation, yet I ultimately found it: it was a faulty cage.
The Alienware Aurora R4 has 3.5" inch hard drive slots. Since this SSD is 2.5", you need to buy a convertor "cage". It simply is a plastic box with inside it a connector. You insert your SSD in the cage into the connector, next you insert the cage as a whole into the HDD slot inside the desktop.
Actually, whether you need this cage or not depends on your exact model. The Alienware Aurora ALX models do need the cage, yet in the Aurora (non-ALX) R4 models, you don't strictly need them. It helps to better align the SSD, but it is not strictly needed, since the connectors are in the front, within reach.
Anyway, based on some Youtube install video I bought myself a Icydock cage. And this eventually turned out to be my mistake. My cage was faulty. Based on online research, it turns out I'm not the only one.
I removed the cage and instead decided to directly connect my SSD to the connectors. And bang, all my problems dissapeared:
- The SSD is now detected in the BIOS
- After booting to Windows on my normal HDD, cloning this time made a clone from C: to C:
- Reboot and change the boot order
- There it is: genuine Windows on C:, using the SSD
8 hours of agony ended in 10 minutes after making the direct connection. With this painful experience behind me, here are some recommendations:
- Investigate whether you need a cage at all, and if you buy one, buy a good one
- If your SSD is not recognized in the BIOS, do not proceed. Check the hardware, update the BIOS, do whatever is required to make that SSD appear in the BIOS
- When cloning, clone from C: to C:. If the data migration tool suggests a different target drive letter and doesn't let you pick C:, something is wrong. Do not proceed.
Help for such very specific scenarios is limited online, so if this helps only one person, I'm happy. You should be enjoying your SSD, instead of wasting your time on these issues.
Enjoying the SSD
Let's end with the good part, actually enjoying the SSD :)
I've only had a day of experience with it so far, but here's some results:
As expected, Windows boots a lot faster. What matters to me most is what happens after signing in to Windows. Normally, it appears to be ready, yet in reality it is still not responsive for 2 minutes or so. That delay is almost entirely gone. A few seconds after signing in, I have a browser open and ready to use.
That's awesome. And this snappy experience carries through all of my actions. Despite using a powerful desktop, I still always had the feeling that I was waiting for it, even for small actions. That friction is now gone. Things happen instantly.
What about photography? As a test, I did a fresh import of 300 RAW photos (45-60MB 36MP files) into Lightroom. I'd normally do such a thing when returning from the field. I'd also pour myself a drink in the meanwhile, as it takes a few minutes. With the SSD, it took mere seconds. I didn't time it, because I didn't expect it to be this fast. I thought something was wrong when it finished in front of my eyes. That's how fast it is.
The other big thing I do is to work with a Linux VM, my main development instance. Normally, I may have a small code change in mind, yet will postpone it, because powering on the VM, my IDE, build tasks and all takes too long. It's too costly to bother for a small change.
Not anymore. This entire LAMP stack is powered on in less than 2 seconds, and shutdown in the same amount of time. All friction is removed, and with it, all my excuses.
I'd like to end with that conclusion: this upgrade isn't just a hardware upgrade. It changes the way I compute at a fundamental level. As of now, friction is removed and the system is waiting for me, instead of me waiting for the system. I know I'm late to the SSD party, but better late than never :)