pfeerick

Well, I do agree we need to stick to web page topic, the other stuff is an elsewhere conversation.  
 
So I spent some time in the documentation github, I saw changes go live instantly on the documentation page, nice.  What is the rate of update on the webpage itself?  I added the ethernet issues to the potato board notes, it wasn't there initially, but was several hours later.  I like the GitHub --> Web page link, that allows for direct community contribution via pull request, and allows for rollback of mistakes.

Did you open the box? Never spot any pictures of the PCB from this box...
 

Unfortunately the DRAM cannot even be initialized on this board.
 
Yes, quite prototype ;-)

I have thrown myself out of the forums at least 6 times today by clicking on the "Armbian" banner image.  

I agree, but wish we had a way to "document-ize" the tutorial after all the discussion.  You get 40 pages of talk on a tutorial and it's easy to miss the important parts.
 
Yes, there is.  I think we run into trouble that there aren't many maintainers to begin with, and we range from " This is good enough I don't need feedback" to "I want 100% absolute direct democracy on every decision".  This is difficult, and there are pros and cons to both.100% direct democracy does quite literally mean nothing gets done in a reasonable time, but everything will be more stable.  "Good Enough" gets you more bugs, but also more on-time releases and a sense that you're "doing something" to the general public.  (See the criticism Debian gets about their definition of "Stable")
 
There is one thing I can say that is hard to dispute:  I can test something pretty thoroughly on my hardware in my laboratory with my equipment.  That doesn't mean it's going to work for anyone else repeatably.  So I test, and I commit the changes.  My changes are immediately live, there is no means to "trial" a change.  This is a discussion for another thread, but we should have a stable "release" branch that only gets updated for bugfixes.  Then our download page would have "Stable Release" and "development" images.  People want to use dev images?  Ok, but know that a 5.37-beta release may not be stable, even if it is a legacy kernel/etc. 
 
 
For the Website: I think a CMS is best.  However, if the primary maintainer of the website is not fond of that idea, then a set of templates and a github would be a wise alternative.

The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.

Linux kernel development is anarchistic and our work is involved, dependant and related to this organizational type. Adding too strick wireframe and being harsh where is absolutely no need might be more damaging ... and a waste of time if you like that kind of word form. Scaring people not to come out with their ideas because somebody will bark at them how stupid they are might be also a waste of time. And damaging. Most people around the project are volunteers after all and demanding ultimate compliance won't work. Being a pro/cash has little effect on this either.

Talking and discussing every possible matter consumes human resources which, frankly we don't have in indefinite capacity. Nobody has. Somebody has to lead and coordinate this web redesign and until this is mostly on me, I will resolve minor disputes instantly or I will not deal with this in any way. This is not a military precision stuff! Why do we need to panic? It's plenty of time, this is not print media and mistakes can be fixed. 
 
And I will for sure do more mistakes in the future. Perhaps even repeat them, which I hope not.

If you think everything is waste of time, take a break from extreme specifics ... even this can be considered as a waste of time from a radical point of view.  

You have possible future boards in the dedicated section and there is a place for discussion if needed. There is no rush - take time. It's your right to write down that all boards sux and is pointless to deal with it. Should this change anything? Not necessarily and it should be this way.
 
Can we now stay on this topic?
 

It's not uncommon that 'Home' isn't visible on a websites navbar,  but the logo is linked to it (said someone who was on armbians main page more than 6 times today.. ).  As soon as you've a template page it's annoying to program exceptions... 
 
IMO this should be discussed in another thread. Otherwise, we fill this one also with a lot of stuff which doesn't belong to the topic.

I'm not sure if we need this carousel on the first page (R1 picture in the draft).  A small "news feed" should also do the job not? Downloadpage might be a little bit confusing (status & release). IMO only the 'Deprecated' flag is needed, on all other boards, you see from the release (testing, stable etc.) the status of your board.  A small 'getting started' guide on the first page is a good idea to avoid the major issues when starting with armbian.

1. How about a uploader top100 to motivate users to share bandwith with torrents ? and that way limit your bandwith use on your servers ? (if it´s a problem)

I just wanted to say that using those expressions as filters/tags is misleading.
 
I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.

I think how to categorize the boards is a separate discussion, I'd link it in closely with the matrix of kernel support I've mentioned elsewhere, then that could be searchable via a specific function (like a filter:  "I want a mainline supported USB3 Gb Eth 64-bit quad core")

I also like Zador's idea for the download section.
 
This I don't understand. I always click  for SoC and if it were then in alphabetical order, would be fine by me.
H3 rush, is ending. H2, H5 and H6 is coming so the quantity of SBC is to me small enough per SoC, that I do not see the reason for a search.
Unless you see indeed a problem.
 
CMS: I agree that it would help. So Igor could count on the help from the community.
 
Docs: I was wondering if we could have another step in it:
Documentation Tutorials  - for example three lines intro text and a link to this or just a tutorial for xyz. This way it wouldn't get lost in the daily chats.

1. Navigation: unified on all pages. 
I think this could easily be achieved when the whole page is maintained with a CMS-System. I don't know how you do it at the moment, but since I maintain some pages with DjangoCMS, I would never go back to not CMS maintained pages. Adding additional pages is a 30 seconds task, they show up in the menu on the right place - it just works.  Since I work mostly with 'standard' bootstrap elements, I can pick them by one click instead of code a single line in HTML.
 
3&4 Download selection: search on devices must be somehow implemented Download board page: rethink and rework
IMOH the download page looks nice but isn't easy to work with. Instead of 3 pages (stable, WIP, Deprecated), we should have one Download page with a better 'search engine' and a status for every board (needs some adjustments to program but would save us a lot of user questions - if I've time I'll do some testings to show what I think how this could look like). 
 
5. Documentation under common theme
As long as we use  MkDocs, I'm not sure how easy it would be to integrate this into a CMS. I like the 'Read the Docs' template for the documentation, not sure if this needs to be unified. 

I think that download pages and device list pages should be redesigned and we should take some popular websites as examples for the layout.
1. For download pages we could have a device picture on the left, stuff like download buttons to the right of that picture and other stuff below that (i.e. Aliexpress product page, Amazon product page).
2. For the device list pages we could have a list layout - one device in a row, picture to the left, name and short description to the right (i.e. Youtube channel videos list page in the old design).
 
To clarify - I'm not talking about copying any design features, I'm talking mostly about changing the layout to fit more important info on the page that is visible without scrolling and to improve the UX.

Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265

To catch write errors that are not reported to the writing program.
 
Please don't try to tell this to manufacturers of low-end SD cards and USB thumb drives. Writing to block devices doesn't have any feedback mechanism that would ensure that data was written correctly. And while some SD cards were becoming read-only after detecting internal issues, other cards just silently failed to overwrite specific blocks.
 
I use a custom write-with-verify procedure integrated with the Armbian build system, and while when I had issues with the card reader writing was aborted with I/O error, writing to bad SD cards can only be detected by reading back and checksumming the data.

I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
 
Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.

Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra
[ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit.  I've added an issue for it, and some explanation as to what broke.
 

All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

At least that is correct  Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. 
 
 
There are only experimental 4.13.y builds and yes its planned when ready and tested.
 

That is completely normal.  SD card content is left as is. We only alter boot environment when SD card is needed for booting.
 

We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board.

Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...

It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.
Regarding solving the problem - IMO we should push a bugfix update in a week, replacing at least board support packages - this will include armhwinfo fixes and will properly mark images as "stable" rather than "user-built".

As an example - as I proposed some time ago: platform specific performance tweaks go to a function in config/sources/$LINUXFAMILY.conf and are maintained there, this function is "extracted" into a separate file that is included by /etc/init.d/armhwinfo
Same with platform specific firstrun tweaks where they are required.
 
this block (IMAGE_TYPE related) can be moved to line 260 and this should fix the problem.

Cosmetic issue. All images are labeled user-build since I have build parameter in a file and that file (lib.config) is read within configuration.sh later than this:
https://github.com/armbian/build/blob/master/lib/main.sh#L69

Moving(or copying) read configuration up?