Blog.txt is Retina Ready!
Now if you include retina images, Blog.txt will automatically replace them if necessary. See the Plugin's Github page for more information. The image below will load at a higher resolution, if necessary:
Now if you include retina images, Blog.txt will automatically replace them if necessary. See the Plugin's Github page for more information. The image below will load at a higher resolution, if necessary:
I have been looking into solutions for making Blog.txt customisable. I think the best way would be to have a default css file and then a custom css file that will add changes they made. I also would want to be able to use variables in CSS. For example, have the ability to change various colours on the site and have them change in multiple locations in the CSS file, with ease. I have heard there are a few solutions to this, but I am not sure which one to choose or why. If anyone has more information on this problem, please let me know.
Before I get into talking about a few new features I've been thinking about and will hopefully implement this semester, I have a few short term goals:
to have both RSS Feeds and basic WYSIWYG Editing working before Spring Break.
One issue I've been thinking about a lot lately is pagination in Blog.txt. I've decided against using "Previous" and "Next" as those may conflict (in word choice) with features in the browser. Not only would the word choice be identical, but the directions they may point and the actual functionality could be entirely different. Why should the same words take an idea in two different directions? This would only create confusion. I chose "Older" and "Newer", which are two words typically not seen with this feature. I think it's a step in the right direction, however I never truly felt comfortable with the decision. I do have an idea or two on how I could fix this design problem. I could implement an "infinite scroll" solution, which would load more posts as the user scrolls down. This is great because every post as you go further down, gets older, which should make sense to the user. There would also not have to be any links to new pages at all. I could probably still modify my current URL arguments so you could load and link to a "page". Is this a better solution? If I implement this feature, should I enable it by default and give the user the ability to chose between standard pagination and infinite scroll?
So why won't I shut up about these two words? I think this a relatively small problem, but still important. I value good design in software. Those little big details are so important (especially to me). So when designing and building such a simple tool, like Blog.txt, details such as this one, are so much more important.
A new feature I plan to add at a later date is WYSIWYG Editing for not only blog posts, but for blog design. Blog design is going to be fairly important in the project, especially if I want it to be adopted by many. A blogging system which only creates blogs identical to mine would not of much help to anyone but myself. I want the user to be able to set up their own personal blog, with of course, their own look and feel. To do this, I would want to implement one general editing mode (only when logged in, obviously). Blog post editing occurs as normal, but right-clicking (or some other way of activation) a section would bring up color sliders and pickers, scaling, font options, etc. This would work for divs, titles, body text, post width. But I would also want a way to "snap" to a specified modular scale, for quick, but perfect, scaling.
I've posted the slides to my presentation today where I presented my three projects.
I have links for pages working now, but it makes me wonder whether I should use '<' and '>' or 'Previous' and 'Next' or 'Older' and 'Newer'. Either way, I've got the functionality working so I can think about which one makes more sense. I may even create that 'infinite' scrolling, but with URL arguments.