4 ms·

Fun is fine, however, it can distract from the task in hand. Accessibility is queen. No criticisms here, just observations on what gets missed generally by peo

Fun is fine, however, it can distract from the task in hand. Accessibility is queen. No criticisms here, just observations on what gets missed generally by people who go too far along the build tools path and overlook things like document structure along the way. The actual document could benefit from HTML5 niceties such as more accessible elements than 'div' and the table elements. Table has its place but the world is moving on to CSS Grid for proper layout of content rather than tables. I prefer to see 'article', 'section' 'aside', 'nav' and even things like 'cite'. For added usefulness to Google a few structured markup snippets for all of your publications will help nicely. The schema.org 'article' is a good place to start on that, you can also render your HTML from this structured data if in JSON+LD if you insist on clever wizardry or just put the Rdfa (or whatever) tags in the HTML. The UX is not truly accessible, the home button is not a good touch target size plus the navigation is against the 'don't make me think' principle. So it might 'move like a rocket' but if the site visitor can't work out how to get the navigation then what is the point? A vast magnitude of time is lost. A favicon could help with accessibility too. If someone has lots open then a tab identifier helps. Go through the necessary to make a PWA instead of a SPA to get that right - nowadays you need lots of different things for 'add to homescreen' and whatnot. Whilst you are at it include some useful metadata in the header for people sharing your page on social media. Set the meta description with 'nosnippet' so Google shows people exactly what you want them to see. Nobody sees your site before Google so it is important. Sometimes a focus on gadgets is counterintuitive, so the inline SVGs base64 encoded might be very clever, but to someone that understands SVGs this makes no sense at all. They are better as document content, not in an img tag and not base64 encoded. They will compress better that way too. If you did the SVGs normally then you can use currentColor to effect a mouseover, you can use their title tags to show some text on the mouseover. Also, writing an SVG as something like this: path d="M384 1408q0 80-56 136t-136 56-136-56-56-136 56-136 136-56 136 56 56 136zm0-512q0 80-56 136t-136 56-136-56-56-136 56-136 136-56 136 56 56 136zm1408 416v192q0 13-9.5 22.5t-22.5 9.5h-1216q-13 0-22.5-9.5t-9.5-22.5v-192q0-13 9.5-22.5t22.5-9.5h1216q13 0 22.5 9.5t9.5 22.5zm-1408-928q0 80-56 136t-136 56-136-56-56-136 56-136 136-56 136 56 56 136zm1408 416v192q0 13-9.5 22.5t-22.5 9.5h-1216q-13 0-22.5-9.5t-9.5-22.5v-192q0-13 9.5-22.5t22.5-9.5h1216q13 0 22.5 9.5t9.5 22.5zm0-512v192q0 13-9.5 22.5t-22.5 9.5h-1216q-13 0-22.5-9.5t-9.5-22.5v-192q0-13 9.5-22.5t22.5-9.5h1216q13 0 22.5 9.5t9.5 22.5z" is a bit bulky when what you really need for that is to do (pseudo svg here) 'group fill=currentColor stroke=none id=circle-and-line' [ 'circle r=[radius]' 'rect x=[origin] y=[origin] width=[width] height=[height]' ] 'use y=[minus-a-bit] href=circle-and-line' 'use y=[plus-a-bit] href=circle-and-line' In that way you can get a super concise and super editable icon for your CV that you can edit and tweak in document. It will also have the currentColor niceties. Sometimes I think that just because you can put sausages in a blender doesn't mean you should. Those SVGs really are wrongful being inlined and base64 encoded when HTML provides perfect and better mechanisms built in for doing whatever it is you are trying to achieve with them. Also, SVGs are best hand drawn for a pet project site, internet SVGs are just the disgorgings of an Adobe product, normally shapes for icons can be drawn with rectangles, circles, polygons and lines specified with integers, the Adobe products use NASA numbers instead (none decimal places). I would say that you would have a lot more fun if you got the basics of document structure, accessibility and awesome SVG goodness done right, with measurables in Google search results and eyeballs. We all live in glass houses and I am definitely throwing stones here with this critique, but the web gets better with a little bit of discussion on these things.

paultopia 8y ago
I certainly think most of this stuff is right. I've been meaning to go through and make the whole thing more semantic, just haven't gotten around to it yet. So I really appreciate your thoughts, most of that stuff is going on the todo list. (Maybe not the SVG stuff; the way I do the SVGs is a lot more convenient for design flexibility.) (But, to the original point, all of those great suggestions are totally compatible with doing things SPA-style. And actually, Vue components are so composable that these kinds of changes should be pretty easy when I get around to them.)
- Theodores 8y ago
  You have some neat SVG icons already, I urge you to refactor them so they are not 'design assets' but fully fledged and fully yours. The exercise of doing them will give you a new string to your bow for solving visual problems. SVGs are like LEGO but a lot more fun, so long as you play with them properly rather than just use ready mades. So same as LEGO then... Once you have done a small set, e.g. your dozen ones, you will be able to have more of this design flexibility, plus you will discover that creative drawing is not actually what usually goes on with Adobe style applications but goes up to a whole new level when you do SVG - because it is code. If embedding SVGs has cool factor, you can make them fully presentational by putting them in CSS custom variables and then using those custom variables in pseudo elements. This is how I do external links, download links etc. The only downside is that you can't radically change the colours on mouseover etc. https://css-tricks.com/solved-with-css-colorizing-svg-backgrounds/ https://css-tricks.com/solved-with-css-colorizing-svg-backgr... Also Google Lea Verou if you want to take pride in your SVGs. To add to your refactoring list, have one stylesheet with everything that changes depending on screen size set as a CSS variable. So at the top have a big list of 'things that change' and the defaults for any screen size. So if you have margin size for instance, set it there for mobile, then, have a media query below the base list of css variables and then update the variable in the media query block. Try to have zero CSS rules in the media queries, have it exclusively setting CSS variables. If you do it this way then you can tell from the CSS where something changes because it has a CSS variable. Done the old way with chunks of CSS in media queries you can't see at a glance if there is more than one place a given rule is defined, done the new way it can be maintained a lot easier. A final thing - you have a lot of table information and CSS grid is absolutely excellent for showing tables. You don't have to explicitly write out all cells, unlike with tables, you can make things with a given class or other attribute go in the correct column keeping your source data semantically neat even if some records do not contain all the fields. Rather than classes you could mark up your 'papers' and references with things like 'cite' tags, 'address' tags or whatever is bestest HTML5 and have these flow into the correct columns without using classes or tables, just a succinct css grid declaration and that is it. The grid layout is much better for speed so you will like it.

paultopia 8y ago

I certainly think most of this stuff is right. I've been meaning to go through and make the whole thing more semantic, just haven't gotten around to it yet. So I really appreciate your thoughts, most of that stuff is going on the todo list. (Maybe not the SVG stuff; the way I do the SVGs is a lot more convenient for design flexibility.) (But, to the original point, all of those great suggestions are totally compatible with doing things SPA-style. And actually, Vue components are so composable that these kinds of changes should be pretty easy when I get around to them.)

Theodores 8y ago
You have some neat SVG icons already, I urge you to refactor them so they are not 'design assets' but fully fledged and fully yours. The exercise of doing them will give you a new string to your bow for solving visual problems. SVGs are like LEGO but a lot more fun, so long as you play with them properly rather than just use ready mades. So same as LEGO then... Once you have done a small set, e.g. your dozen ones, you will be able to have more of this design flexibility, plus you will discover that creative drawing is not actually what usually goes on with Adobe style applications but goes up to a whole new level when you do SVG - because it is code. If embedding SVGs has cool factor, you can make them fully presentational by putting them in CSS custom variables and then using those custom variables in pseudo elements. This is how I do external links, download links etc. The only downside is that you can't radically change the colours on mouseover etc. https://css-tricks.com/solved-with-css-colorizing-svg-backgrounds/ https://css-tricks.com/solved-with-css-colorizing-svg-backgr... Also Google Lea Verou if you want to take pride in your SVGs. To add to your refactoring list, have one stylesheet with everything that changes depending on screen size set as a CSS variable. So at the top have a big list of 'things that change' and the defaults for any screen size. So if you have margin size for instance, set it there for mobile, then, have a media query below the base list of css variables and then update the variable in the media query block. Try to have zero CSS rules in the media queries, have it exclusively setting CSS variables. If you do it this way then you can tell from the CSS where something changes because it has a CSS variable. Done the old way with chunks of CSS in media queries you can't see at a glance if there is more than one place a given rule is defined, done the new way it can be maintained a lot easier. A final thing - you have a lot of table information and CSS grid is absolutely excellent for showing tables. You don't have to explicitly write out all cells, unlike with tables, you can make things with a given class or other attribute go in the correct column keeping your source data semantically neat even if some records do not contain all the fields. Rather than classes you could mark up your 'papers' and references with things like 'cite' tags, 'address' tags or whatever is bestest HTML5 and have these flow into the correct columns without using classes or tables, just a succinct css grid declaration and that is it. The grid layout is much better for speed so you will like it.